Le calcul d'un hachage MD5 est-il moins gourmand en ressources CPU que SHA-1 ou SHA-2 sur le matériel x86 "standard" des ordinateurs portables ? Je suis intéressé par des informations générales, pas spécifiques à une certaine puce.
UPDATE : Dans mon cas, je suis intéressé par le calcul du hachage d'un fichier. Si la taille du fichier est importante, supposons qu'il s'agit de 300K.
Oui, MD5 est un peu moins gourmand en ressources CPU. Sur mon Intel x86 (Core2 Quad Q6600, 2,4 GHz, utilisant un cœur), j'obtiens ceci en mode 32 bits :
MD5 411
SHA-1 218
SHA-256 118
SHA-512 46et ce en mode 64 bits :
MD5 407
SHA-1 312
SHA-256 148
SHA-512 189Les chiffres sont exprimés en mégaoctets par seconde, pour un message "long" (c'est ce que vous obtenez pour les messages de plus de 8 kB). C'est avec sphlib Une bibliothèque d'implémentations de fonctions de hachage en C (et Java). Toutes les implémentations sont du même auteur (moi) et ont été faites avec des efforts comparables d'optimisations ; ainsi les différences de vitesse peuvent être considérées comme réellement intrinsèques aux fonctions.
À titre de comparaison, considérez qu'un disque dur récent fonctionne à environ 100 Mo/s, et que tout ce qui est transmis par USB ne dépasse pas 60 Mo/s. Même si SHA-256 semble "lent" ici, il est suffisamment rapide pour la plupart des besoins.
Notez que OpenSSL inclut une implémentation 32-bit de SHA-512 qui est plus rapide que mon code (mais pas aussi rapide que SHA-512 64-bit), parce que l'implémentation d'OpenSSL est en assembleur et utilise des registres SSE2, ce qui ne peut être fait en C. SHA-512 est la seule fonction parmi ces quatre qui bénéficie d'une implémentation SSE2.
Editar: en cette page ( archives ), on peut trouver un rapport sur la vitesse de nombreuses fonctions de hachage (cliquez sur le lien "Telechargez maintenant"). Le rapport est en français, mais il est surtout rempli de tableaux et de chiffres, et les chiffres sont internationaux. Les fonctions de hachage implémentées n'incluent pas les candidats SHA-3 (sauf SHABAL) mais je travaille dessus.
Je ne pense pas que vos benchmarks soient utiles. Une comparaison de vitesse de deux algorithmes basée sur une optimisation équivalente mais incomplète n'est pas pertinente. Dans le monde réel, vous n'utilisez pas votre propre implémentation, mais plutôt des implémentations entièrement optimisées. Ce sont les résultats de celles-ci qui doivent être comparés.
@EdwardBrey En fait, ils sont assez proches d'être entièrement optimisés. En fait, son implémentation de md5 fonctionne beaucoup plus rapidement que celle proposée par OpenSSL, donc toutes les implémentations ne seront pas optimisées dans le "monde réel" comme vous le dites. De plus, même si elles ne sont pas parfaites (vous avez raison sur ce point), elles constituent une réponse parfaite à cette question particulière.
Pourrions-nous obtenir une mise à jour sur les processeurs modernes et les implémentations modernes des algorithmes ? Votre réponse a été utilisée au moins une fois pour justifier la poursuite de l'utilisation du MD5, quinze ans après qu'il ait été prouvé qu'il était cassé et plusieurs années après que des attaques par pré-image se soient produites dans le monde réel, pour créer des fichiers PE malveillants signés avec le MD5 comme algorithme de résumé qui produisent le même résumé exact que celui trouvé dans la signature originale. Et c'est ainsi que la signature a été transplantée. Le MD5, puis le SHA-1, ont depuis été supprimés de la signature. L'OP demandait un hachage, donc même en 2010 le fait de pousser le MD5 n'était pas un conseil judicieux.
Sur mon Macbook Air 2012 (Intel Core i5-3427U, 2x 1,8 GHz, 2,8 GHz Turbo), SHA-1 est légèrement plus rapide que MD5 (en utilisant OpenSSL en mode 64 bits) :
$ openssl speed md5 sha1
OpenSSL 0.9.8r 8 Feb 2011
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 30055.02k 94158.96k 219602.97k 329008.21k 384150.47k
sha1 31261.12k 95676.48k 224357.36k 332756.21k 396864.62kMise à jour : 10 mois plus tard, avec OS X 10.9, SHA-1 est devenu plus lent sur la même machine :
$ openssl speed md5 sha1
OpenSSL 0.9.8y 5 Feb 2013
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 36277.35k 106558.04k 234680.17k 334469.33k 381756.70k
sha1 35453.52k 99530.85k 206635.24k 281695.48k 313881.86kDeuxième mise à jour : Sous OS X 10.10, la vitesse de SHA-1 est revenue au niveau de 10.8 :
$ openssl speed md5 sha1
OpenSSL 0.9.8zc 15 Oct 2014
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 35391.50k 104905.27k 229872.93k 330506.91k 382791.75k
sha1 38054.09k 110332.44k 238198.72k 340007.12k 387137.77kTroisième mise à jour : OS X 10.14 avec LibreSSL est beaucoup plus rapide (toujours sur la même machine). SHA-1 est toujours en tête :
$ openssl speed md5 sha1
LibreSSL 2.6.5
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 43128.00k 131797.91k 304661.16k 453120.00k 526789.29k
sha1 55598.35k 157916.03k 343214.08k 489092.34k 570668.37k
Bizarre, mon air est le même que le tien et j'ai obtenu des résultats opposés. avec 8192 bytes : md5 305549.52k ; sha1 204668.57k
Hmm, j'obtiens également des résultats différents de ceux de l'année dernière sur la même machine : md5 381756.70k, sha1 313881.86k. Peut-être à cause de la mise à jour vers 10.9 (OpenSSL 0.9.8y).
En tant que personne qui a passé un peu de temps à optimiser les performances du MD5 Je me suis dit que j'allais fournir une explication plus technique que les repères fournis ici, à l'intention de tous ceux qui trouveraient cette information à l'avenir.
MD5 effectue moins de "travail" que SHA1 (par exemple, moins de tours de compression), on pourrait donc penser qu'il devrait être plus rapide. Cependant, l'algorithme MD5 est principalement une grande chaîne de dépendance, ce qui signifie qu'il n'exploite pas particulièrement bien les processeurs superscalaires modernes (c'est-à-dire qu'il présente un faible nombre d'instructions par horloge). SHA1 dispose de plus de parallélisme et, bien qu'il ait besoin de plus de "travail de calcul", il est souvent plus rapide que MD5 sur les processeurs superscalaires modernes.
Si vous effectuez la comparaison entre MD5 et SHA1 sur des processeurs plus anciens ou dont la "largeur" superscalaire est moindre (comme un processeur Atom basé sur Silvermont), vous constaterez généralement que MD5 est plus rapide que SHA1.
SHA2 et SHA3 sont encore plus gourmands en ressources informatiques que SHA1, et généralement beaucoup plus lents.
Il convient toutefois de noter que certains nouveaux processeurs x86 et ARM disposent d'instructions permettant d'accélérer SHA1 et SHA256, ce qui aide évidemment beaucoup ces algorithmes si ces instructions sont utilisées.
Par ailleurs, les performances de SHA256 et SHA512 peuvent présenter un comportement tout aussi curieux. SHA512 effectue plus de "travail" que SHA256, mais une différence essentielle entre les deux est que SHA256 fonctionne avec des mots de 32 bits, tandis que SHA512 fonctionne avec des mots de 64 bits. Ainsi, SHA512 sera généralement plus rapide que SHA256 sur une plate-forme avec une taille de mot de 64 bits, car il traite deux fois la quantité de données à la fois. Inversement, SHA256 devrait être plus rapide que SHA512 sur une plate-forme avec une taille de mot de 32 bits.
Notez que tout ce qui précède ne s'applique qu'au hachage d'un seul tampon (de loin le cas d'utilisation le plus courant). Si vous êtes fantaisiste et que vous calculez plusieurs hachages en parallèle, c'est-à-dire une approche SIMD multi-buffers, le comportement change quelque peu.
La vraie réponse est : Cela dépend
Il y a plusieurs facteurs à prendre en compte, les plus évidents étant : le processeur sur lequel vous exécutez ces algorithmes et l'implémentation des algorithmes.
Par exemple, mon ami et moi utilisons exactement la même version d'openssl et obtenons des résultats légèrement différents avec des cpus Intel Core i7 différents.
Mon test au travail avec un processeur Intel(R) Core(TM) i7-2600 @ 3.40GHz
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 64257.97k 187370.26k 406435.07k 576544.43k 649827.67k
sha1 73225.75k 202701.20k 432679.68k 601140.57k 679900.50kEt le sien avec un Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 51859.12k 156255.78k 350252.00k 513141.73k 590701.52k
sha1 56492.56k 156300.76k 328688.76k 452450.92k 508625.68kNous utilisons tous les deux exactement les mêmes binaires d'OpenSSL 1.0.1j 15 Oct 2014 du paquetage officiel d'ArchLinux.
Mon opinion à ce sujet est qu'avec la sécurité supplémentaire de sha1, les concepteurs de processeurs sont plus susceptibles d'améliorer la vitesse de sha1 et plus de programmeurs travailleront sur l'optimisation de l'algorithme que md5sum.
Je suppose que md5 ne sera plus utilisé un jour puisqu'il semble qu'il ne présente aucun avantage par rapport à sha1. J'ai également testé quelques cas sur des fichiers réels et les résultats étaient toujours les mêmes dans les deux cas (probablement limités par les E/S du disque).
Le md5sum d'un gros fichier de 4,6 Go a pris exactement le même temps que le sha1sum du même fichier, de même que de nombreux petits fichiers (488 dans le même répertoire). J'ai effectué les tests une douzaine de fois et j'ai obtenu les mêmes résultats de manière constante.
--
Il serait très intéressant d'approfondir cette question. Je suppose qu'il y a des experts qui pourraient fournir une réponse solide à la raison pour laquelle sha1 devient plus rapide que md5 sur les nouveaux processeurs.
@owlstead damn, j'ai oublié de désactiver le "mode lent" de mes boîtes Linux quand j'ai essayé ça.
@Johnride, ne pas faire de benchmarking à partir d'un fichier. Exécutez-le à partir de données en mémoire ou, plus simplement encore, répétez la même valeur.
Le MD5 bénéficie également de l'utilisation de SSE2. Essayez BarsWF et dites-moi que ce n'est pas le cas. Tout ce qu'il faut, c'est un peu de connaissances en assembleur et vous pouvez créer votre propre routine SSE2 MD5. Pour de grandes quantités de débit cependant, il y a un compromis entre la vitesse pendant le hachage et le temps passé à réarranger les données d'entrée pour être compatible avec les instructions SIMD utilisées.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Ce n'est pas une réponse à votre question, mais les partisans de Skein mettent en avant sa vitesse, et elle n'est certainement pas plus faible que le MD5 en fin de vie à l'heure actuelle. Si les messages que vous devez hacher sont très courts, la vitesse peut être un inconvénient pour une fonction de hachage cryptographique (plus précisément, la vitesse à laquelle quelqu'un d'autre peut l'implémenter, et non la vitesse à laquelle elle fonctionne sur votre ordinateur portable). schneier.com/skein1.2.pdf
4 votes
@Pascal : Skein n'est pas le plus rapide des candidats SHA-3, cependant, surtout sur les plateformes 32 bits. Sur un x86 64 bits, Skein atteint environ 300 Mo/s (Skein-512 étant un peu plus rapide que Skein-256), ce qui est comparable à SHA-1, mais en mode 32 bits, les performances tombent à moins de 60 Mo/s, soit deux fois moins vite que SHA-256. D'autre part, SHABAL, un autre candidat SHA-3, offre des performances similaires à SHA-1 sur les plateformes 32 et 64 bits.