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();
    }

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.

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.

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.

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".

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.

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.

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.

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.

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