Discussion :

[Patrick Ruiz]

Adam Langley : « SHA-3 n’apporte pas grand-chose par rapport à SHA-2, on pourrait s’en passer »
La team Keccak répond à l’ingénieur de Google

SHA-2, la famille d’algorithmes de hachage sécurisé est, depuis les constats de défaillance de l'algorithme de hachage sécurisé SHA-1, pressentie pour lui succéder. Le processus de migration vers SHA-2 annoncé par de nombreuses organisations est en cours. On sait depuis 2012 que la famille d’algorithmes sécurisés SHA-3 devrait succéder à SHA-2 en cas de défaillance constatée de cette dernière qui, faudrait-il le rappeler, est basée sur SHA-1. Adam Langley, ingénieur sécurité chez Google a, fin mai, réagi à cet état de choses en déclarant que « SHA-3 n’apporte pas grand-chose par rapport à SHA-2, on pourrait s’en passer. »

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 ?

Qu’en pensez-vous ?

Quel commentaire faites-vous des déclarations d’Adam Langley ?

Voir aussi :

SHA-1 : Microsoft suit l'exemple de Mozilla et opte pour une fin de support en juin 2016 au lieu de janvier 2017 sur son navigateur
Google annonce la fin du support de SHA-1 dans Chrome, la firme accélère la mort de l'algorithme de hachage cryptographique
Facebook et Cloudflare proposent des solutions pour continuer à utiliser SHA-1 après l'abandon de ce standard pour ne pas léser certains internautes

[BlueScreenJunky]

Pour ma part je ne rencontre au quotidien que deux utilisation de hashage :
1 - Vérifier si une donnée a été modifiée (auquel cas le md5 est très rapide et fait parfaitement le boulot)
2 - Hasher des mots de passe, auquel cas il faut que l'algorithme soit le plus lent possible, et dans ce cadre la lenteur de sha-3 est un avantage.

[Aiekick]

pourquoi tu dit quand pour hasher un pass il faut que l'algo soit le plus lent possible ? je suis pas sur de comprendre.

merci.

[neuneutrinos]

La lenteur est pratique dans le sens où cela diminuera la fréquence des tentatives pour casser.
Mais dans la pratique, je n'ai pas envie d'attendre 1 minutes par hachage.
Il y a un compromis à faire en fonction du contexte.

[Invité]

pourquoi tu dit quand pour hasher un pass il faut que l'algo soit le plus lent possible ? je suis pas sur de comprendre.

merci.

le hashing de mot de passe est une mesure de sécurité qui intervient une fois que la base de données a fuité. A partir de ce moment là, la méthode "classique" pour l'attaquant pour retrouver les mots de passes initiaux, c'est la brute-force, donc essayer toutes les combinaisons possibles. C'est pour cela qu'un hash lent lui posera plus de soucis qu'un hash rapide.
D'ailleurs, pour hasher les mot de passe on conseille des algorithmes à complexité (et donc vitesse) paramétrable comme pbkdf2 ou bcrypt plutot que des algos à visées généralistes comme les SHA-XXX.

[abriotde]

C'est pour cela qu'un hash lent lui posera plus de soucis qu'un hash rapide

Pas vraiment. Si l'on récupère une base de 10 000 ou plus de mot de passe hashé, on ne va pas tester tous les mots de passe sur chacun des 10 000 mot de passe. Le plus simple est de hasher quelque chose comme 1 milliard de mot de passe simple et ensuite de les comparer avec les 10 000 de notre base. Mais dans tous les cas on ne pourra pas hasher la totalité des mot de passe possible mais seulement les plus "simples" et si algorithme de hachage est 3 fois plus lent, on hashera simplement 3 fois moins de mot de passe ce qui ne change au final pas grand chose, on reste dans le même ordre de grandeur.
Explication : avec les 10 000 mot de passe les plus courant on décodera quelque chose comme 30% des mots de passe. Avec 100 000 on en décodera 50% avec 1000 000, 65% avec 1 000 000 000, 75%... En fait ce qu'il faut retenir C'est que décoder 100% des mots de passe est quasi-impossible et que la quantité le nombre de mot de passe à tester augmente exponentiellement avec le pourcentage. La raison en est simple, on trouve facilement la majorité des mot de passe simple mais les mot de passe qui reste sont les plus complexes.

[Invité]

Pas vraiment. Si l'on récupère une base de 10 000 ou plus de mot de passe hashé, on ne va pas tester tous les mots de passe sur chacun des 10 000 mot de passe.

En fait, si. C'est à ça que sert le "sel", un élément d'entropie supplémentaire, unique par mot de passe et combiné à celui-ci, qui oblige l'attaquant à recommencer tout son système pour chaque mot de passe.

Je m'explique:
Si on considère h = hash(mdp), effectivement, on génère tous les hash(caractères_possibles) et on a une belle table de correspondance, utilisable partout.
Si on fait h = hash(sel + hash(mdp)) avec un sel aléatoire (>64bits) et unique, alors il faut générer toutes les combinaisons possibles pour chaque sel + hash(caractères_possibles), en commençant par des entrées > 64b, ... bon courage

A titre d'exemple, un SHA-256 se génère à ~10MH/s sur un CPU récent, je ne parle même pas des GPU ou ASIC (~facteur 100), si on paramètre une fonction de dérivation de clé (de préférence GPU résistant) pour forcer un travail de 1ms par hash, on est à 1kH/s

[Volgaan]

De toute façon de nos jours on ne hashe plus simplement les mots de passe. On leur ajoute au minimum un sel ou, bien mieux, on utilise une fonction comme bcrypt(), qui utilise Blowfish en interne et possède une difficulté variable qu'il est possible de changer n'importe quand

Je vous invite à lire ce lien si le sujet de sécurité des mots de passe vous intéresse.