Affichage des résultats du sondage: Quel est l’algorithme de hachage qui offre les meilleures performances en vitesse ?

Votants
3. Vous ne pouvez pas participer à ce sondage.
  • BLAKE2

    0 0%
  • K12

    1 33,33%
  • Autres, précisez

    1 33,33%
  • Je n'ai pas d'avis sur la question

    1 33,33%
+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 334
    Points : 10 822
    Points
    10 822

    Par défaut Adam Langley : « SHA-3 n’apporte pas grand-chose par rapport à SHA-2, on pourrait s’en passer »

    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.


    Nom : graphe.png
Affichages : 2183
Taille : 27,8 Ko


    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2012
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2012
    Messages : 33
    Points : 85
    Points
    85

    Par défaut

    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.

  3. #3
    Membre expérimenté
    Homme Profil pro
    Consultant Ingenierie mécanique
    Inscrit en
    mars 2006
    Messages
    804
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant Ingenierie mécanique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2006
    Messages : 804
    Points : 1 737
    Points
    1 737

    Par défaut

    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.

  4. #4
    Membre habitué
    Étudiant
    Inscrit en
    juin 2010
    Messages
    65
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2010
    Messages : 65
    Points : 183
    Points
    183

    Par défaut

    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.

  5. #5
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 33
    Points : 323
    Points
    323

    Par défaut

    Citation Envoyé par Aiekick Voir le message
    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.

  6. #6
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    542
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 542
    Points : 915
    Points
    915

    Par défaut

    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.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  7. #7
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2017
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2017
    Messages : 33
    Points : 323
    Points
    323

    Par défaut

    Citation Envoyé par abriotde Voir le message
    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

  8. #8
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2011
    Messages
    136
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : janvier 2011
    Messages : 136
    Points : 286
    Points
    286

    Par défaut

    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.

Discussions similaires

  1. c'est pas grand chose..
    Par supertunar dans le forum Langage
    Réponses: 6
    Dernier message: 07/02/2008, 15h27
  2. Comment se compliquer la vie pour pas grand chose
    Par alsimbad dans le forum Macros et VBA Excel
    Réponses: 3
    Dernier message: 15/08/2007, 07h17
  3. [RegExp] Avis aux Initiés, j'y connais pas grand chose
    Par Okena dans le forum JavaScript
    Réponses: 4
    Dernier message: 04/05/2007, 16h31
  4. [VBA-E] Je ne connais pas grand chose VBA + Excel
    Par nicolasdeloise dans le forum Macros et VBA Excel
    Réponses: 6
    Dernier message: 17/01/2007, 23h58
  5. Giptables..je trouve pas grand chose
    Par irnatene dans le forum Réseau
    Réponses: 3
    Dernier message: 18/09/2006, 14h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo