
Adam Langley estime que « le suffixe 3 accolé à SHA- est un leurre qui a tendance à faire croire aux gens que SHA-3 est forcément meilleur que SHA-2 ». Il soutient qu’en raison du nombre important de combinaisons qu’il faut prendre en compte dans le cadre de l’implémentation de SHA-3, le code gagne en volume, un luxe qu’on ne peut se permettre avec l’avènement des appareils mobiles et leurs ressources limitées. Il enchaîne ensuite avec une comparaison en termes de vitesse entre SHA-3 et SHA-2 lorsqu’il déclare que « SHA-3 est également lent, plus lent que SHA-2 qui n’est pas un modèle de vitesse en comparaison à d’autres standards. Nous ne voulons pas d’un autre algorithme de hachage lent, SHA-2 est déjà dans cette situation. »
Adam Langley affirme que « le déploiement de SHA-256 et SHA-512 est largement suffisant et que point n’est besoin de disposer d’un algorithme de hachage supplémentaire ». Pour ces raisons, il déclare que « je pense que SHA-3 ne devrait pas être utilisé. Par rapport à SHA-2, il n’y a pas de réel avantage à en faire usage. De plus, il introduit des coûts supplémentaires ». Il est d’avis qu’en cas de défaillance de SHA-2, il y a de meilleurs candidats que SHA-3 pour ce qui est du critère vitesse. Il a notamment fait allusion au standard BLAKE2 qui a été publié avant que SHA-3 ne soit donné vainqueur de la compétition organisée par l’institut américain des standards et de la technologie (NIST) entre 2008 et 2012.
L’équipe SHA-3 vient de réagir aux propos d’Adam Langley, particulièrement pour ce qui est du critère vitesse. Il faudrait signaler que la vitesse à laquelle il est fait allusion ici est la capacité d’un processeur à exécuter plus ou moins rapidement l’algorithme de hachage. L’équipe SHA-3 oppose à Adam Langley l’argument du nécessaire compromis entre sécurité et vitesse. Pour des applications demandant un maximum de sécurité, alors, d’après elle, une implémentation de SHA3-512 devrait théoriquement pouvoir rendre satisfaction, ce, bien sûr au détriment de la vitesse comme elle le souligne.
Par contre, pour ce qui est du manque de vitesse auquel Adam Langley s'accroche particulièrement, l’équipe SHA-3 présente deux niveaux de solutions offerts par la famille de fonctions de hachage SHA-3. Le premier niveau de solution offre des performances en vitesse similaires à SHA-2 via les fonctions de sortie extensibles SHAKE128 et SHAKE256. Pour ce qui est du second, SHA-3 devrait carrément supplanter tous les autres standards existants en vitesse. Les chercheurs soulignent en effet qu’il existe une variante de SHA-3 dénommée KangarooTwelve (K12) dédiée à des applications exigeantes en vitesse, ce, bien sûr, au détriment de la sécurité. Les chercheurs ont d’ailleurs publié un graphe des performances obtenues avec K12 en comparaison avec d’autres standards sur un Skylake cadencé à 3,2 Ghz.
Il faudrait souligner en passant que K12 est à la famille de fonctions cryptographiques SHA-3 ce que BLAKE2 est à BLAKE, l’un des algorithmes de hachage finaliste de la compétition organisée par le NIST entre 2008 et 2012. BLAKE apporte sécurité au détriment de la vitesse, ce qui est l’inverse de BLAKE2. Ainsi, à défaut de rester sur SHA-2 et passer à BLAKE2 en cas de défaillance de SHA-2 comme semble le suggérer Adam Langley, l’on pourrait aussi migrer de SHA-2 à K12 pour coller au critère vitesse.
Sources : ImperialViolet, keccak
Et vous ?


Voir aussi :


