Question:
Quelles sont les crypto-monnaies réalistes et les plus sûres pour les chiffrements Symmetric, Asymmetric, Hash, Message Authentication Code?
goodguys_activate
2011-01-20 04:40:21 UTC
view on stackexchange narkive permalink

Je suis intéressé par la mise à jour de cette question à deux volets pour 2011:

  1. Quelle cryptologie est la plus appropriée pour les appareils de faible puissance (comme un téléphone portable), et pourtant toujours efficace ?

  2. Quelle cryptologie est la plus sécurisée pour un développeur .NET?

En novembre 2008 Rasmus Faber a répondu à cette question similaire à Stack Overflow avec cette réponse:

  • Chiffrement symétrique: AES-256

  • Chiffrement asymétrique: RSA avec une clé de 4096 bits (je crois que c'est le maximum dans .NET) ou ECDSA avec une clé de 571 bits (mais qui n'est prise en charge que dans .NET 3.5)

  • Hash: SHA-512

  • Code d'authentification de message: HMAC avec SHA-512

Cela étant dit, ils sont exagérés pour la plupart des applications, et vous devriez se débrouille bien avec AES-128, RSA avec clé de 2048 bits, SHA-256 et HMAC avec SHA-256.

Ces recommandations sont-elles toujours vraies aujourd'hui?

Votre mise à jour d'avril pour ajouter le graphique par "fournisseur de chiffrement de RIM" ajoute beaucoup de confusion. C'est vraiment une publicité pour le matériel ECC de Certicom avec des longueurs RSA surdimensionnées ajoutées pour l'effet. Ils citent trompeusement les travaux de la NSA et du NIST. Comme d’autres l’ont déjà précisé, même les recommandations précédentes étaient exagérées. Je suggère simplement de supprimer la mise à jour ou de la publier comme réponse, car la mise à jour de la question ne permet pas non plus de savoir à quoi les réponses précédentes faisaient référence à moins que les gens ne vérifient les dates.
@nealmcb - J'ai pensé que c'était utile ... Je l'ai enlevé. Merci pour les commentaires
Il peut être intéressant de souligner que l'exigence spécifique d'un hachage pour le stockage des mots de passe est différente de l'exigence d'un hachage pour l'intégrité des messages (qu'il s'agisse de transmission ou de signature). scrypt / bcrypt / PBKDF2 - mais SHA-256 / SHA-512 n'est certainement pas la bonne réponse.
Quelqu'un pourrait-il écrire la liste des chiffrements les plus courants qui peuvent être utilisés ~ en toute sécurité de nos jours?
@boleslaw.smialy La réponse de Rasmus Faber est un résumé concis - voir aussi keylength.io
Sept réponses:
#1
+38
Thomas Pornin
2011-01-20 05:29:19 UTC
view on stackexchange narkive permalink

Les recommandations que vous citez sont un peu exagérées. Un point à prendre en compte est qu'au-delà d'un certain niveau (par exemple sur la taille de la clé ou la taille de sortie de la fonction de hachage), toutes les fonctions sont "incassables avec une technologie prévisible" et il est un peu délicat de les comparer. Dire que SHA-512 est "plus robuste" que SHA-256 signifie que vous imaginez que SHA-256 pourrait être cassé, ce qui, d'après ce que nous pouvons dire pour le moment et les 40 prochaines années, n'est pas vrai (au-delà de 40 ans , essayer d'imaginer quelle technologie nous pourrions avoir est risqué; il y a 40 ans, personne n'imaginait Internet tel qu'il est aujourd'hui, mais la plupart des gens pensaient que d'ici 2010 nous conduirions tous des voitures volantes).

AES- 128 est déjà suffisamment sécurisé et moins cher (AES-256 utilise 14 tours, tandis que AES-128 utilise 10 tours).

La plus grande clé RSA cassée actuellement est un module de 768 bits, et il en a fallu un peu énorme effort (quatre ans, et de très gros cerveaux). Les clés de 1024 bits sont considérées comme utilisables pour la sécurité à court terme, bien que les clés plus grandes soient encouragées. Les clés de 2048 bits sont appropriées. L'utilisation d'une clé deux fois plus grande signifie 8 fois plus de travail pour la signature ou le décryptage, vous ne voulez donc pas en faire trop. Consultez ce site pour une étude sur la manière dont la longueur de clé RSA peut être liée à la sécurité.

ECDSA sur une courbe de 256 bits atteint déjà un niveau de sécurité "incassable" (c'est-à-dire à peu près au même niveau que AES avec une clé de 128 bits, ou SHA-256 contre les collisions). Notez qu'il existe des courbes elliptiques sur les champs premiers et des courbes sur les champs binaires; quel type est le plus efficace dépend du matériel impliqué (pour les courbes de taille similaire, un PC préférera les courbes sur un champ principal, mais le matériel dédié sera plus facile à construire avec des champs binaires; les instructions CLMUL sur les nouveaux processeurs Intel et AMD peuvent changer cela).

SHA-512 utilise des opérations 64 bits. C'est rapide sur un PC, pas si rapide sur une carte à puce. SHA-256 est souvent une meilleure affaire sur le petit matériel (y compris les architectures 32 bits telles que les routeurs domestiques ou les smartphones).

À l'heure actuelle, les systèmes RFID bon marché sont trop peu puissants pour utiliser l'un des systèmes ci-dessus (en d'autres termes, les systèmes RFID qui ne sont pas aussi bon marché qu'ils pourraient l'être). Les systèmes RFID utilisent encore des algorithmes personnalisés de sécurité souvent discutable. Les téléphones portables, en revanche, ont suffisamment de puissance CPU pour effectuer une cryptographie appropriée avec AES ou RSA (oui, même des téléphones non intelligents bon marché).

http://keylength.com/ donne quelques recommandations pour les tailles données par an, ou les années données les tailles etc.
#2
+11
Rasmus Faber
2011-01-20 15:39:09 UTC
view on stackexchange narkive permalink

La réponse citée est ma réponse à ce qui est le crypto le plus sécurisé dans .NET.

Mes recommandations (à la fois pour les -périphériques alimentés):

  • Chiffrement symétrique: AES-128

  • Chiffrement asymétrique: RSA avec clé de 2048 bits ou ECDSA / ECDH avec clé de 256 bits

  • Hash: SHA-256

  • Code d'authentification de message: HMAC avec SHA-256

  • Chiffrement de flux: AES-128 en mode CTR

#3
+6
PulpSpy
2011-01-20 05:09:21 UTC
view on stackexchange narkive permalink

En termes de sécurité, ces recommandations sont toujours valables et les mêmes que je ferais.

Pour les chiffrements asymétriques, il y a vraiment trois choses qui vous préoccupent: le chiffrement, l'échange de clés et les signatures. RSA peut être à la fois un schéma de cryptage et de signature, tandis que ECDSA est spécifiquement une signature. Cependant, il existe également des versions à courbe elliptique du cryptage et de l'échange de clés (pas sûr de ce qui est dans le domaine public). Cela dit, les tailles des paramètres sont les mêmes pour les trois.

Le seul autre problème est que SHA-256/512 sera bientôt remplacé mais "bientôt" dans ce cas sera 2012.

En ce qui concerne la faible puissance, cela dépend vraiment de la faible puissance. Si par téléphone portable, vous entendez un smartphone, tout cela est approprié. Pour une carte à puce, une RFID, un réseau de capteurs, etc., c'est une autre histoire. De plus, la plupart des algorithmes de faible puissance ne seront pas dans une bibliothèque standard. Cependant, je vous orienterais vers les tailles de paramètre dans la dernière phrase "not overkill".

On ne sait pas si SHA-3 (choisi en 2012) "remplacera" SHA-2 (SHA-256 et SHA-512). Le NIST n'a certainement pas prétendu cela. Il semble que SHA-3 a été initié afin d'être prêt si SHA-2 devait être cassé, mais SHA-2 s'avère assez résilient.
C'est suffisant. Je crois que la résilience de SHA-2 peut être artificiellement gonflée par tous les cryptanalyseurs se concentrant sur les candidats SHA-3 et non sur la rupture de SHA-2. ;)
De plus, la liste manque un chiffrement de flux - avez-vous une recommandation @Thomas?
Un «chiffrement de flux» est principalement un contexte d'utilisation spécifique; AES en mode CTR est un chiffrement de flux. Si nous voulons quelque chose de plus rapide, nous pouvons regarder des algorithmes spécialement conçus pour cela; la chose intelligente est de regarder le [Portfolio eSTREAM] (http://www.ecrypt.eu.org/stream/). Je choisirais Sosemanuk, mais je suis légèrement partial sur cette question.
#4
+6
nealmcb
2011-01-20 22:03:49 UTC
view on stackexchange narkive permalink

Pour la sécurité jusqu'en 2030, les experts du NIST recommandent d'utiliser au moins SHA-224, 2048 bits pour RSA ou DSA, 224 bits EDCSA et AES-128 ou triple DES à 3 clés.

Sur la base de leurs travaux, à la fin de 2010, le gouvernement américain désapprouve ces algorithmes: SHA-1, RSA ou DSA 1024 bits, ECDSA 160 bits (courbes elliptiques), 2TDEA 80/112 bits (two key triple DES)

Pour plus d'informations, consultez cet article et les documents NIST auxquels il fait référence: http://securitymusings.com/article/1587/algorithm-and-key-length- obsolète

TripleDES est compromis en raison de deux petites tailles de bloc (64 bits).
J'ai entendu dire que c'est vrai, @boleslaw.smialy, par exemplepour certains modes de fonctionnement authentifiés, mais un pointeur vers plus d'informations serait utile.Et je conviens qu'en général, AES est meilleur que n'importe laquelle de ces formes de triple DES.
#5
+5
Bruno Rohée
2011-04-07 20:47:33 UTC
view on stackexchange narkive permalink

Cryptographic Right Answers par Colin Percival en 2009 est encore assez à jour à mon humble avis et couvre la question et plus.

#6
+2
Justin Clarke
2011-01-20 05:16:37 UTC
view on stackexchange narkive permalink

Pour les chiffrements symétriques, il se peut que vous fassiez mieux d'utiliser AES-128 au lieu d'AES-256 en raison de possibles faiblesses dans le calendrier clé pour AES-256: http://www.schneier.com/blog/archives/ 2009/07 / another_new_aes.html

Je suis complètement en désaccord. C'est une interprétation totalement erronée de ces résultats. (Je connais bien ce domaine.) Ces résultats ne sont pas applicables à la plupart des utilisations d'AES (ni même à toute utilisation appropriée d'AES). De plus, aucun des résultats cités ici ne s'applique au chiffrement AES-256 complet à 14 coups.
http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html en a plus sur ce sujet, essentiellement si vous avez choisi votre clé au hasard (ce qui est bon pour les protocoles), ces attaques de clés associées sont sans aucune importance.
#7
  0
Dave
2011-01-20 05:56:56 UTC
view on stackexchange narkive permalink

Ce que nous avons fait, c'est de sélectionner plusieurs méthodes de chiffrement et de hachage et de convertir toutes les sorties dans un format hexadécimal commun. Nos données les plus sensibles utilisent SHA-256 et DES-3, tandis que les données moins sensibles qui peuvent être devinées facilement utilisent MD5 & RC4 et nous utilisons également une conversion XOR directe pour certaines choses. Chaque chiffrement symétrique a son propre mot de passe et toutes les données chiffrées sont codées avec une somme de contrôle. S'appuyer sur un seul cryptage pour tout est dangereux.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...