Quels sont les cryptos réalistes et les plus sécurisés pour les chiffrements de code d'authentification de message symétrique, asymétrique, de hachage?
Je souhaite mettre à jour cette question à deux volets pour 2011:
Quelle cryptologie est la plus appropriée pour les appareils de faible puissance (comme un téléphone portable), tout en restant efficace?
Quelle cryptologie est la plus sécurisée pour un développeur .NET?
En novembre 2008 Rasmus Faber a répondu this question Stack Overflow similaire 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 en .NET) ou ECDSA avec une clé de 571 bits (mais qui n'est pris en charge que dans .NET 3.5)
Hachage: SHA-512
Code d'authentification du message: HMAC avec SHA-512
Cela étant dit, ceux-ci sont exagérés pour la plupart des applications, et vous devriez bien utiliser AES-128, RSA avec une clé de 2048 bits, SHA-256 et HMAC avec SHA-256.
Ces recommandations sont-elles toujours vraies aujourd'hui?
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 la sortie de la fonction de hachage), toutes les fonctions sont "incassables avec la 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, pour autant que nous puissions en juger pour l'instant 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 qu'en 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 clé RSA cassée la plus importante actuellement est un module de 768 bits, et cela a pris un effort énorme (quatre ans et un cerveau vraiment gros). Les clés de 1024 bits sont considérées comme utilisables pour la sécurité à court terme, bien que des clés plus grandes soient encouragées. Les clés à 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échiffrement, donc vous ne voulez pas en faire trop. Voir ce site pour un aperçu de la façon 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 le 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; le type le plus efficace dépend du matériel impliqué (pour des 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; le CLMUL les instructions 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 vite 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 éléments 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 toujours 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 les téléphones non intelligents bon marché).
La réponse citée est ma réponse à ce qu'est la cryptographie la plus sécurisée dans .NET.
Mon recommandations (pour les appareils à puissance élevée et faible):
Chiffrement symétrique: AES-128
Chiffrement asymétrique: RSA avec clé 2048 bits ou ECDSA/ECDH avec clé 256 bits
Hachage: SHA-256
Code d'authentification de message: HMAC avec SHA-256
Chiffrement de flux: AES-128 en mode CTR
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 chiffrement 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 (je ne sais pas exactement ce qui est dans le domaine public). Cela dit, les tailles des paramètres sont les mêmes pour les trois.
Le seul autre cavet 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 voulez dire un smartphone, tous ces éléments sont appropriés. Pour une carte à puce, RFID, 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ètres dans la dernière phrase "pas trop exagéré".
Pour la sécurité jusqu'en 2030, les gens avisés 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, fin 2010, le gouvernement américain déprécie ces algorithmes: SHA-1, RSA ou DSA 1024 bits, ECDSA 160 bits (courbes elliptiques), 80/112 bits 2TDEA (deux clés triple DES) )
Pour plus d'informations, consultez cet article et les documents du NIST auxquels il fait référence: http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation
Cryptographic Right Answers par Colin Percival en 2009 est toujours à peu près à jour à mon humble avis et couvre la question et plus encore.
Pour les chiffrements symétriques, il est préférable d'utiliser AES-128 au lieu d'AES-256 en raison de faiblesses possibles dans le calendrier clé pour AES-256: http://www.schneier.com/blog/archives/2009/ 07/another_new_aes.html
Ce que nous avons fait 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 et RC4 et nous utilisons également une conversion droite XOR pour certaines choses). Chaque chiffrement symétrique a son propre mot de passe et toutes les données chiffrées sont saisies avec une somme de contrôle. Se fier à un chiffrement pour tout est dangereux.