Quelle fonction de hachage cryptographique dois-je choisir?

137

Le framework .NET est livré avec 6 algorithmes de hachage différents:

  • MD5: 16 octets (temps de hachage 500 Mo: 1462 ms)
  • SHA-1: 20 octets (1644 ms)
  • SHA256: 32 octets (5618 ms)
  • SHA384: 48 octets (3839 ms)
  • SHA512: 64 octets (3820 ms)
  • RIPEMD: 20 octets (7066 ms)

Chacune de ces fonctions fonctionne différemment; MD5 étant le plus rapide et RIPEMD étant le plus lent.

MD5 a l'avantage de s'intégrer dans le type Guid intégré; et c'est la base de l'UUID de type 3 . Le hachage SHA-1 est la base de l'UUID de type 5. Ce qui les rend vraiment faciles à utiliser pour l'identification.

MD5 est cependant vulnérable aux attaques par collision , SHA-1 est également vulnérable, mais dans une moindre mesure.

Dans quelles conditions dois-je utiliser quel algorithme de hachage?

Les questions particulières auxquelles je suis vraiment curieux de voir des réponses sont:

  • MD5 n'est-il pas digne de confiance? Dans des situations normales, lorsque vous utilisez l'algorithme MD5 sans intention malveillante et qu'aucun tiers n'a d'intention malveillante, vous attendez-vous à TOUTES les collisions (c'est-à-dire deux octets arbitraires [] produisant le même hachage)

  • À quel point RIPEMD est-il meilleur que SHA1? (si c'est mieux) il est 5 fois plus lent à calculer mais la taille de hachage est la même que SHA1.

  • Quelles sont les chances d'obtenir des collisions non malveillantes lors du hachage de noms de fichiers (ou d'autres chaînes courtes)? (Par exemple, 2 noms de fichiers aléatoires avec le même hachage MD5) (avec MD5 / SHA1 / SHA2xx) En général, quelles sont les chances de collisions non malveillantes?

C'est le benchmark que j'ai utilisé:

    static void TimeAction(string description, int iterations, Action func) {
        var watch = new Stopwatch();
        watch.Start();
        for (int i = 0; i < iterations; i++) {
            func();
        }
        watch.Stop();
        Console.Write(description);
        Console.WriteLine(" Time Elapsed {0} ms", watch.ElapsedMilliseconds);
    }

    static byte[] GetRandomBytes(int count) {
        var bytes = new byte[count];
        (new Random()).NextBytes(bytes);
        return bytes;
    }


    static void Main(string[] args) {

        var md5 = new MD5CryptoServiceProvider();
        var sha1 = new SHA1CryptoServiceProvider();
        var sha256 = new SHA256CryptoServiceProvider();
        var sha384 = new SHA384CryptoServiceProvider();
        var sha512 = new SHA512CryptoServiceProvider();
        var ripemd160 = new RIPEMD160Managed();

        var source = GetRandomBytes(1000 * 1024);

        var algorithms = new Dictionary<string,HashAlgorithm>();
        algorithms["md5"] = md5;
        algorithms["sha1"] = sha1;
        algorithms["sha256"] = sha256;
        algorithms["sha384"] = sha384;
        algorithms["sha512"] = sha512;
        algorithms["ripemd160"] = ripemd160;

        foreach (var pair in algorithms) {
            Console.WriteLine("Hash Length for {0} is {1}", 
                pair.Key, 
                pair.Value.ComputeHash(source).Length);
        }

        foreach (var pair in algorithms) {
            TimeAction(pair.Key + " calculation", 500, () =>
            {
                pair.Value.ComputeHash(source);
            });
        }

        Console.ReadKey();
    }
Sam Safran
la source
15
Le fait que vous mentionniez md5 correspond au format GUID (16 octets) suggère un malentendu fondamental. Un hachage n'est pas garanti d'être unique, mais il est rare (et difficile à simuler s'il est utilisé dans un sens cryptographique) et dérivé de la chose dont il est un hachage tandis qu'un GUID est, eh bien, unique mais sans rapport avec le contenu du chose qu'il identifie. Ils sont utilisés à des fins très différentes.
Barry Wark le
1
Corrigez son non lié, c'est juste un fait spécifique de mise en œuvre pratique. Je comprends que vous ne pouvez pas insérer l'infini dans un 16 octets. Vous pouvez obtenir des collisions avec N'IMPORTE QUEL algorithme de hachage
Sam Saffron
5
De plus, un Guid est juste en pratique unique, en théorie, si vous continuiez à générer des Guids, vous obtiendriez éventuellement des doublons.
Sam Saffron le
3
Vous ne devriez vraiment pas insérer un hachage dans un GUID, même s'il correspond. Exemple le plus simple: deux copies du même fichier doivent avoir des GUID différents, mais le même hachage. Les 8 premières lettres du nom d'une personne correspondent également assez bien à 16 octets.
dbkk le
2
@ user2332868 La rupture de SHA-1 n'a aucun effet sur la probabilité de collisions accidentelles . Lorsqu'une intention malveillante est une menace pour votre utilisation, je pense que choisir aveuglément une fonction de hachage est une erreur et que vous devez passer du temps à analyser les risques / coûts pour votre cas spécifique.
Andrey Tarantsov

Réponses:

138

En cryptographie, les fonctions de hachage fournissent trois fonctions distinctes.

  1. Résistance aux collisions : Quelle est la difficulté pour quelqu'un de trouver deux messages ( deux messages quelconques ) qui ont le même hachage.
  2. Preimage Resistance : Étant donné un hachage, est-il difficile de trouver un autre message qui hache le même? Également connue sous le nom de fonction de hachage à sens unique .
  3. Deuxième résistance de préimage : étant donné un message, trouvez un autre message qui hache le même.

Ces propriétés sont liées mais indépendantes. Par exemple, la résistance aux collisions implique une seconde résistance de pré-image, mais pas l'inverse. Pour une application donnée, vous aurez des exigences différentes, nécessitant une ou plusieurs de ces propriétés. Une fonction de hachage pour sécuriser les mots de passe sur un serveur ne nécessitera généralement qu'une résistance à la pré-image, tandis que les résumés de messages nécessitent les trois.

Il a été montré que le MD5 n'est pas résistant aux collisions, ce qui n'empêche pas son utilisation dans des applications qui ne nécessitent pas de résistance aux collisions. En effet, MD5 est souvent encore utilisé dans des applications où la plus petite taille de clé et la vitesse sont bénéfiques. Cela dit, en raison de ses défauts, les chercheurs recommandent l'utilisation d'autres fonctions de hachage dans de nouveaux scénarios.

SHA1 a un défaut qui permet de trouver des collisions en théorie beaucoup moins que les 2 ^ 80 étapes qu'une fonction de hachage sécurisée de sa longueur exigerait. L'attaque est continuellement révisée et peut actuellement être effectuée en ~ 2 ^ 63 étapes - à peine dans le domaine actuel de la calculabilité. Pour cette raison, le NIST abandonne progressivement l'utilisation de SHA1, déclarant que la famille SHA2 devrait être utilisée après 2010.

SHA2 est une nouvelle famille de fonctions de hachage créée à la suite de SHA1. Il n'y a actuellement aucune attaque connue contre les fonctions SHA2. SHA256, 384 et 512 font tous partie de la famille SHA2, en utilisant simplement des longueurs de clé différentes.

RIPEMD Je ne peux pas trop commenter, sauf pour noter qu'il n'est pas aussi couramment utilisé que les familles SHA et qu'il n'a donc pas été examiné d'aussi près par les chercheurs en cryptographie. Pour cette seule raison, je recommanderais l'utilisation des fonctions SHA par-dessus. Dans l'implémentation que vous utilisez, cela semble également assez lent, ce qui le rend moins utile.

En conclusion, il n'y a pas de meilleure fonction - tout dépend de ce dont vous en avez besoin. Soyez conscient des défauts de chacun et vous serez le mieux à même de choisir la bonne fonction de hachage pour votre scénario.

Eric Burnett
la source
1
Je vous remercie vraiment d'entrer dans ce niveau de détail. C'est très utile.
joelc
1
Pour certaines applications, même une fonction de hachage non cryptographique peut être appropriée. L'OP n'a jamais mentionné si c'était spécifiquement pour les mots de passe, ou pour l'authentification par défi-réponse, ou pour les jetons d'accès, ou simplement pour indexer un tas de chaînes / fichiers. La performance, en revanche, est une préoccupation pour l'OP ...
Seva Alekseyev
111

Toutes les fonctions de hachage sont "cassées"

Le principe du casier dit qu'essayer aussi fort que vous le souhaitez, vous ne pouvez pas mettre plus de 2 pigeons dans 2 trous (à moins que vous ne coupiez les pigeons). De même, vous ne pouvez pas insérer 2 ^ 128 + 1 nombres dans 2 ^ 128 emplacements. Toutes les fonctions de hachage aboutissent à un hachage de taille finie, cela signifie que vous pouvez toujours trouver une collision si vous recherchez à travers "taille finie" + 1 séquences. Ce n'est tout simplement pas possible de le faire. Pas pour MD5 et pas pour Skein .

MD5 / SHA1 / Sha2xx n'ont aucun risque de collision

Toutes les fonctions de hachage ont des collisions, c'est une réalité. Traverser ces collisions par accident équivaut à gagner à la loterie intergalactique . C'est-à-dire que personne ne gagne à la loterie intergalactique , ce n'est tout simplement pas la façon dont la loterie fonctionne. Vous ne rencontrerez JAMAIS un hachage MD5 / SHA1 / SHA2XXX accidentel. Chaque mot de chaque dictionnaire, dans chaque langue, a une valeur différente. Chaque nom de chemin, sur chaque machine de la planète entière a un hachage MD5 / SHA1 / SHA2XXX différent. Comment puis-je savoir cela, demandez-vous. Eh bien, comme je l'ai déjà dit, personne ne gagne à la loterie intergalactique, jamais.

Mais ... MD5 est cassé

Parfois le fait qu'il soit cassé n'a pas d'importance .

Dans l'état actuel des choses, il n'y a pas d' attaque connue de pré-image ou de seconde pré-image sur MD5.

Alors, qu'est-ce qui est si cassé à propos de MD5, demandez-vous? Il est possible pour un tiers de générer 2 messages, dont un est EVIL et un autre est BON que les deux hachent à la même valeur. ( Attaque par collision )

Néanmoins, la recommandation RSA actuelle est de ne pas utiliser MD5 si vous avez besoin d'une résistance pré-image. Les gens ont tendance à faire preuve de prudence en ce qui concerne les algorithmes de sécurité.

Alors, quelle fonction de hachage dois-je utiliser dans .NET?

  • Utilisez MD5 si vous avez besoin de la vitesse / taille et que vous ne vous souciez pas des attaques d'anniversaire ou des attaques pré-image.

Répétez ceci après moi, il n'y a aucune chance de collision MD5 , les collisions malveillantes peuvent être soigneusement conçues. Même s'il n'y a pas d'attaques de pré-image connues à ce jour sur MD5, la ligne des experts en sécurité est que MD5 ne doit pas être utilisé là où vous devez vous défendre contre les attaques de pré-image. SAME va pour SHA1 .

Gardez à l'esprit que tous les algorithmes n'ont pas besoin de se défendre contre les attaques de pré-image ou de collision. Prenons le cas trivial d'une première recherche de fichiers en double sur votre disque dur.

  • Utilisez la fonction basée sur SHA2XX si vous voulez une fonction de hachage cryptographiquement sécurisée.

Personne n'a jamais trouvé de collision SHA512. DÉJÀ. Ils ont vraiment essayé. D'ailleurs, personne n'a jamais trouvé de collision SHA256 ou 384. .

  • N'utilisez pas SHA1 ou RIPEMD sauf si c'est pour un scénario d'interopérabilité.

RIPMED n'a pas reçu le même examen minutieux que SHAX et MD5. SHA1 et RIPEMD sont tous deux vulnérables aux attaques d'anniversaire. Ils sont tous deux plus lents que MD5 sur .NET et ont une taille maladroite de 20 octets. Il est inutile d'utiliser ces fonctions, oubliez-les.

Les attaques de collision SHA1 sont réduites à 2 ^ 52, ce ne sera pas trop long jusqu'à ce que les collisions SHA1 soient dans la nature.

Pour obtenir des informations à jour sur les différentes fonctions de hachage, consultez le zoo des fonctions de hachage .

Mais attendez, il y a plus

Avoir une fonction de hachage rapide peut être une malédiction. Par exemple: une utilisation très courante des fonctions de hachage est le stockage des mots de passe. Essentiellement, vous calculez le hachage d'un mot de passe combiné avec une chaîne aléatoire connue (pour empêcher les attaques arc-en-ciel) et stockez ce hachage dans la base de données.

Le problème est que si un attaquant obtient un vidage de la base de données, il peut, assez efficacement, deviner les mots de passe en utilisant la force brute. Chaque combinaison qu'il essaie ne prend qu'une fraction de milliseconde, et il peut essayer des centaines de milliers de mots de passe par seconde.

Pour contourner ce problème, l' algorithme bcrypt peut être utilisé, il est conçu pour être lent afin que l'attaquant soit fortement ralenti s'il attaque un système utilisant bcrypt. Récemment, scrypt a fait la une des journaux et est considéré par certains comme plus efficace que bcrypt, mais je ne connais pas d'implémentation .Net.

Sam Safran
la source
Alors que MD5 et SHA-1 ont été affaiblis, MD5 est beaucoup plus faible que SHA-1, bien que légèrement plus rapide. Des collisions MD5 réelles ont été trouvées et utilisées pour des exploits dans le monde réel (forger des certificats CA), mais pour autant que je sache, aucune collision réelle SHA-1 n'a été trouvée (bien que le nombre d'opérations ait été considérablement réduit par la force brute). Et étant donné à quel point MD5 est plus faible, je ne serais pas surpris si les secondes attaques de pré-image apparaissaient plus tôt pour MD5 que pour SHA-1. Ainsi, je pense que vous devriez utiliser SHA-1 si vous avez besoin de vitesse et non de résistance aux collisions, et sinon, utilisez l'un de la famille SHA-2.
Brian Campbell
1
@Brian il est assez clair que dans les prochaines années, les gens pourront lancer des attaques par collision sur SHA1, cela rendra effectivement SHA1 aussi utile que MD5, le certificat CA est une attaque par collision, de même dans quelques années, les gens pourront pour exécuter la même attaque sur les certificats CA SHA1. L'attaque dépend d'une partie malveillante créant un EVIL et un bon certificat. Il n'y a pas d'attaques de primage connues sur MD5 et le fait qu'il y ait des attaques par collision ne rend pas les attaques pré-image plus ou moins probables.
Sam Saffron
Il s'agit beaucoup moins de savoir quel hachage vous utilisez pour les mots de passe, que de ce qui est haché. Si votre sel est connu, votre base de données est immédiatement vulnérable à une attaque par dictionnaire; si votre salt est procédural et que votre système de fichiers est compromis, vous êtes (à nouveau) vulnérable; si votre sel est omis, vous êtes à nouveau compromis. La sécurité en cause est, quoi qu'il arrive, ce qui est haché. Certificats, je ne parlerai pas car je ne les ai pas traités en tant que programmeur (IE, création, compréhension, etc.).
Robert K
Le terme cassé a une signification spécifique dans le contexte du hachage, et ce n'est pas le sens sur lequel cette réponse met l'accent. Cette réponse ne fera que semer la confusion.
Joel McBeth
1
C'est une excellente réponse car elle met l'accent sur l'aspect pratique. Les hachages sont utilisés pour des choses autres que la sécurité (comme la génération de clés de recherche de cache pour les données non sensibles ou la détermination si un objet sérialisé a changé). Les chances d'une attaque ciblée sont pratiquement nulles (ne dites jamais jamais), et même si une attaque réussissait, elle n'aurait aucun impact matériel. Excellent travail axé sur l'impact pratique (plutôt que théorique).
DVK
35

Mettre à jour:

Les temps ont changé, nous avons un gagnant SHA3. Je recommanderais d'utiliser keccak (aka SHA3 ) gagnant du concours SHA3.

Réponse originale:

Par ordre du plus faible au plus fort, je dirais:

  1. RIPEMD BROKEN, ne doit jamais être utilisé comme on peut le voir dans ce pdf
  2. MD-5 BROKEN, ne doit jamais être utilisé, peut être cassé en 2 minutes avec un ordinateur portable
  3. SHA-1 BROKEN, ne doit jamais être utilisé, est cassé en principe, les attaques s'améliorent de semaine en semaine
  4. SHA-2 FAIBLE, Sera probablement cassé dans les prochaines années. Quelques faiblesses ont été trouvées.Notez qu'en général, plus la taille de clé est élevée, plus la fonction de hachage est difficile à casser. Bien que la taille de la clé = force ne soit pas toujours vraie, c'est généralement vrai. Donc SHA-256 est probablement plus faible que SHA-512.
  5. Skein NO KNOWN FAIBLESSES, est un candidat pour SHA-3 . Il est assez récent et donc non testé.Il a été implémenté dans plusieurs langues.
  6. MD6 PAS DE FAIBLESSES CONNUES, est un autre candidat pour SHA-3. Probablement plus fort que Skien, mais plus lent sur les machines monocœur. Comme Skien, il n'a pas été testé. Certains développeurs soucieux de la sécurité l'utilisent dans des rôles critiques .

Personnellement, j'utiliserais MD6, car on ne peut jamais être trop paranoïaque. Si la vitesse est un réel problème, je regarderais Skein ou SHA-256.

Ethan Heilman
la source
5
Je ne placerais pas Skein et MD6 aussi haut dans la liste; il y a une raison pour laquelle le concours SHA-3 ne sera pas terminé avant la fin de 2012. Il faut beaucoup de temps et beaucoup d'yeux pour être convaincu qu'une fonction de hachage est en fait susceptible d'être sécurisée, et aucune de ces fonctions existent depuis assez longtemps pour cela.
Eric Burnett
Je partage vos sentiments, mais je pense que la communauté est dans une situation étrange. Toutes les fonctions de hachage utilisées sont dangereusement proches d'être cassées (peut-être, peut-être, pas SHA2 256-512) et pourtant nous devons attendre 2012 pour choisir un remplacement. choisissez votre poison: faible / cassé ou non testé (la plupart des candidats au NIST n'ont pas été rendus publics depuis plus de 6 mois)? Choix difficile.
Ethan Heilman
5
RIPEMD est cassé, mais RIPEMD-128/160/256 est différent et non cassé.
Bwooce
Je ne connais aucune implémentation performante de Skein pour .NET. J'ai rencontré SkeinFish et nskein, et les deux étaient très lents.
Cocowalla
1
J'attendrais avec SHA-3 jusqu'à ce que la norme réelle soit disponible, du moins si vous voulez réellement suivre une norme. L'algorithme lui-même a trop d'options.
Paŭlo Ebermann
3

Dans la défense de MD5, il n'existe aucun moyen connu de produire un fichier avec un hachage MD5 arbitraire. L'auteur original doit planifier à l'avance une collision fonctionnelle. Ainsi, si le destinataire fait confiance à l'expéditeur, MD5 convient. MD5 est cassé si le signataire est malveillant, mais il n'est pas connu pour être vulnérable aux attaques de type "man-in-the-middle".

rlbond
la source
1
Bien que je ne sois en aucun cas un expert dans ce domaine, n'est-il pas proche de la possibilité de calculer des hachages MD5 arbitraires par force brute de nos jours?
mafu
@mafu: Réponse tardive ici, mais il est possible de calculer n'importe quel hachage via la force brute. Cela pourrait simplement prendre beaucoup de temps.
Warty
@ItzWarty Je faisais spécifiquement référence au temps nécessaire - comme MD5 est assez court, j'ai pensé qu'il serait peut-être possible de simplement y jeter une source de calcul raisonnable (E3, ou une grille informatique bon marché, quelques machines avec quelques cartes graphiques, quelque chose dans ce sens) et être capable de calculer un hachage MD5 arbitraire en quelques jours, par exemple.
mafu
@mafu Une attaque pré-image coûte 2 ^ 127 appels de hachage pour un hachage de 128 bits. C'est loin d'être réalisable. 2 ^ 80 invocations sont possibles mais déjà très coûteuses.
CodesInChaos
2

Celui que vous utilisez dépend vraiment de l'utilisation que vous en faites. Si vous voulez simplement vous assurer que les fichiers ne sont pas corrompus pendant le transport et que vous ne vous souciez pas de la sécurité, optez pour le rapide et le petit. Si vous avez besoin de signatures numériques pour des accords de sauvetage fédéraux de plusieurs milliards de dollars et que vous devez vous assurer qu'ils ne sont pas falsifiés, optez pour une usurpation et un ralentissement.

Tvanfosson
la source
1
Souvent, lorsque je discute de solutions au problème, je mentionne que j'utilise MD5 pour une identité rapide (hachage d'une chaîne), ils disent "mais md5 est cassé ... ne l'utilisez pas, utilisez sha1" ... Je ne suis pas vraiment abonné à cela me demandais si quelque chose est si fondamentalement rompu avec certains des hachages les plus faibles qu'ils devraient être évités ... par exemple, des cas de travaux réels où des données normales produisent des collisions
Sam Saffron
Étant donné que MD5 a bien fonctionné pour des millions de personnes pendant quinze ans, je soupçonne que ce n'est pas grave pour vous si la sécurité de hachage n'est pas cruciale.
mqp
2
@sambo MD5 fonctionne très bien dans presque tous les cas, sauf lorsque la sécurité / l'intégrité réelle de votre système dépend de la prévention des collisions.
Rex M
2

Je voudrais signaler (avant que md5 ne soit déchiré) que j'utilise encore beaucoup md5 malgré son écrasement écrasant pour beaucoup de crypto.

Tant que vous ne vous souciez pas de vous protéger contre les collisions (vous pouvez également utiliser md5 dans un hmac en toute sécurité) et que vous voulez la vitesse (parfois vous voulez un hachage plus lent), vous pouvez toujours utiliser md5 en toute confiance.

Mike Boers
la source
@Mike Je suis avec vous là-dessus, c'est un peu ce que je cherchais avec cette question, c'est quelque chose à propos des fonctions de hachage les plus faibles si fondamentalement brisées qu'elles ne devraient jamais être utilisées.
Sam Saffron
De plus, si les données ou la sécurité requise des données ont une durée de vie plus courte que la période de fissure (quelques minutes ces jours-ci iirc), MD5 est tout à fait correct. Le point est utile sur le plan situationnel mais toujours utile.
annakata
@annakata - Gardez à l'esprit que vous devrez également éviter de réutiliser des clés dans plusieurs messages pour qu'il soit utilisable dans ces circonstances.
Steve Westbrook
2

Ce serait une bonne idée de jeter un œil à l' algorithme BLAKE2 .

Comme il est décrit, il est plus rapide que MD5 et au moins aussi sûr que SHA-3. Il est également implémenté par plusieurs applications logicielles , dont WinRar.

Florin Mircea
la source
Cela pourrait être plus rapide, sauf que de nombreuses implémentations ont un support matériel, ce qui rend SHA-256 assez rapide.
zaph
Je suis d'accord. à partir de 2019, Blake2b est le meilleur hachage à usage général publié à ce jour. Significativement plus rapide que toutes les autres alternatives, et non moins sécurisé (du moins pas de manière significative), et peut être exécuté dans seulement 336 octets de RAM (168 pour blake2s), oh, et il est optimisé pour les processeurs little-endian, ce qui est l'endian dominant sur les systèmes d'aujourd'hui.
hanshenrik
0

Je ne suis pas un expert dans ce genre de choses, mais je suis au courant de la communauté de la sécurité et beaucoup de gens considèrent que le hachage md5 est cassé. Je dirais que celui à utiliser dépend de la sensibilité des données et de l'application spécifique. Vous pourrez peut-être vous en sortir avec un hachage légèrement moins sécurisé tant que la clé est bonne et forte.

bleu intégral
la source
1
Les fonctions de hachage n'utilisent généralement pas de clés
Ethan Heilman
0

Voici mes suggestions pour vous:

  1. Vous devriez probablement oublier MD5 si vous prévoyez des attaques. Il existe de nombreuses tables arc-en-ciel pour eux en ligne, et des sociétés comme la RIAA sont connues pour être capables de produire des séquences avec des hachages équivalents.
  2. Utilisez un sel si vous le pouvez. Inclure la longueur du message dans le message peut rendre très difficile la création d'une collision de hachage utile.
  3. En règle générale, plus de bits signifie moins de collisions (par principe de casier) et plus lentes, et peut-être plus sûres (à moins que vous ne soyez un génie des mathématiques qui puisse trouver des vulnérabilités).

Voir ici un article détaillant un algorithme permettant de créer des collisions md5 en 31 secondes avec un ordinateur de bureau Intel P4.

http://eprint.iacr.org/2006/105

Inconnue
la source
Ce commentaire est très ancien et semble plutôt enterré, mais ce bit - les RIAA sont connus pour être capables de produire des séquences avec des hachages équivalents - m'a sauté dessus, et je suis très curieux de savoir quel était le contexte. En particulier, le bruteforcing MD5 il y a 8 ans était un peu moins trivial qu'en 2017, donc ils devaient avoir une assez bonne raison.
i336_