Quelle fonction de hachage cryptographique dois-je choisir?
Le framework .NET est livré avec 6 algorithmes de hachage différents:
- MD5: 16 octets (Temps nécessaire pour hacher 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 effectue différemment; MD5 étant le plus rapide et RIPEMD étant le plus lent.
Le MD5 présente l’avantage de s’insérer dans le type Guid intégré; et c'est la base de l'UUID de type . Le hachage SHA-1 est la base de l'UUID de type 5. Ce qui les rend vraiment faciles à utiliser pour l'identification.
Cependant, MD5 est vulnérable à attaques par collision , SHA-1 est également vulnérable mais dans une moindre mesure.
Dans quelles conditions dois-je utiliser quel algorithme de hachage?
Des questions particulières qui m'intéressent vraiment sont:
Ne faut-il pas faire confiance à MD5? Dans des situations normales, lorsque vous utilisez l'algorithme MD5 sans intention malveillante et qu'aucun tiers n'a d'intention malveillante, vous vous attendez à N'IMPORTE QUELLE collision (signifiant deux octets arbitraires [] produisant le même hachage)
RIPEMD est-il meilleur que SHA1? (si sa est meilleure) son 5 fois plus lente à 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 collision non malveillantes?
C'est la référence que j'ai utilisée:
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.
- Résistance à la collision: Il est difficile pour quelqu'un de trouver deux messages ( ou deux deux messages) ayant le même caractère de hachage.
- Résistance à la pré-image: Avec un hachage, est-il difficile de trouver un autre message qui a le même hachage? Aussi appelé fonction de hachage à sens unique .
- Deuxième résistance pré-image: Étant donné un message, trouvez un autre message qui a le même caractère.
Ces propriétés sont liées mais indépendantes. Par exemple, la résistance à la collision implique une deuxième résistance à la pré-image, mais pas l'inverse. Pour toute application donnée, vous aurez différentes exigences, nécessitant une ou plusieurs de ces propriétés. Une fonction de hachage permettant de sécuriser les mots de passe sur un serveur ne requiert généralement que la résistance à la pré-image, tandis que la synthèse de messages requiert les trois.
Il a été démontré que le MD5 n’est pas résistant aux collisions, ce qui n’empêche pas son utilisation dans des applications ne requérant pas de résistance aux collisions. En effet, le MD5 est encore souvent utilisé dans des applications où la taille et la rapidité des clés sont bénéfiques. Cela dit, en raison de ses défauts, les chercheurs recommandent d’utiliser d’autres fonctions de hachage dans de nouveaux scénarios.
SHA1 a une faille qui permet de trouver des collisions théoriquement beaucoup moins importantes que les 2 ^ 80 étapes requises par une fonction de hachage sécurisée de sa longueur. L’attaque est constamment révisée et peut actuellement être réalisée en ~ 2 ^ 63 étapes - à peine dans le domaine actuel de la calculabilité. Pour cette raison, le NIST élimine 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éées à la suite de SHA1. Il n'y a actuellement aucune attaque connue contre les fonctions SHA2. Les SHA256, 384 et 512 font tous partie de la famille SHA2 et utilisent simplement des longueurs de clé différentes.
RIPEMD Je ne peux pas trop en dire, sauf pour noter que ce n'est pas aussi commun que les SHA familles) et n'a donc pas été aussi minutieusement examiné par les chercheurs en cryptographie. Pour cette raison seul, je recommanderais l’utilisation des fonctions SHA). Dans l’implémentation que vous utilisez, il semble également être 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 avez besoin. Soyez attentif aux défauts de chacun et vous serez 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 pigeon dit que, si vous voulez, vous ne pouvez pas installer plus de 2 pigeons dans 2 trous (à moins que vous ne les coupiez). De même, vous ne pouvez pas insérer 2 ^ 128 + 1 numéros dans 2 ^ 128 emplacements. Toutes les fonctions de hachage donnent un hachage de taille finie, ce qui signifie que vous pouvez toujours trouver une collision si vous effectuez une recherche dans des séquences de "taille finie" + 1. Ce n'est tout simplement pas faisable. Pas pour MD5 et pas pour Skein .
MD5/SHA1/Sha2xx n'ont aucune collision accidentelle
Toutes les fonctions de hachage ont des collisions, c'est un fait de la vie. Reconnaître ces collisions par accident équivaut à remporter la loterie intergalactique . C'est-à-dire personne ne gagne à la loterie intergalactique , ce n'est tout simplement pas la façon dont fonctionne la loterie. Vous ne rencontrerez JAMAIS de hash MD5/SHA1/SHA2XXX accidentel. Chaque mot dans 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, vous pouvez demander. Eh bien, comme je l'ai déjà dit, personne ne gagne la loterie intergalactique, jamais.
Mais ... MD5 est cassé
Parfois, le fait que son cassé n'ait pas d'importance .
Dans l'état actuel des choses, il n'y a pas de pré-images ou deuxièmes attaques de pré-images sur MD5.
Alors, qu'est-ce qui brise si mal dans le MD5? Il est possible pour un tiers de générer 2 messages, dont l'un est EVIL et l'autre, GOOD, qui ont tous deux une valeur identique. ( attaque par collision )
Néanmoins, la recommandation RSA actuelle est de ne pas utiliser MD5 si vous avez besoin d'une résistance avant image. Les gens ont tendance à faire preuve de prudence en ce qui concerne les algorithmes de sécurité.
Alors, quelle fonction de hachage devrais-je utiliser dans .NET?
- Utilisez MD5 si vous avez besoin de vitesse/taille et que vous ne vous souciez pas des attaques d’anniversaire ou des attaques pré-image.
Répétez cette opération après moi , il n’ya aucune chance que des collisions MD5 , des collisions malveillantes puissent être soigneusement manipulées. Bien qu'il n'y ait pas d'attaques de pré-image connues à ce jour sur MD5, les experts en sécurité estiment que MD5 ne doit pas être utilisé lorsque vous devez vous défendre contre des attaques de pré-image. SAME s'applique à SHA1 .
N'oubliez pas que tous les algorithmes n'ont pas besoin de se défendre contre les attaques par pré-image ou par collision. Prenons le cas trivial d’une première recherche de fichiers dupliqués sur votre disque dur.
- Utilisez la fonction SHA2XX si vous souhaitez une fonction de hachage sécurisée par cryptographie.
Personne n'a jamais trouvé de collision SHA512. DÉJÀ. Ils ont vraiment essayé. Pour cette raison, personne n'a jamais trouvé de collision SHA256 ou 384. .
- N'utilisez pas SHA1 ou RIPEMD sauf dans le cas d'un scénario d'interopérabilité.
RIPMED n'a pas reçu le même degré de contrôle que SHAX et MD5. SHA1 et RIPEMD sont vulnérables aux attaques d'anniversaire. Ils sont tous deux plus lents que MD5 sur .NET et ont une taille de 20 octets. Son inutile d'utiliser ces fonctions, les oublier.
Les attaques par collision SHA1 sont réduites à 2 ^ 52, il ne faudra pas attendre longtemps avant que les collisions SHA1 ne se déroulent dans la nature.
Pour des informations à jour sur les différentes fonctions de hachage, regardez la fonction de hachage Zoo .
Mais attendez il y a plus
Avoir une fonction de hachage rapide peut être une malédiction. Par exemple: le stockage de mots de passe est une utilisation très courante des fonctions de hachage. Essentiellement, vous calculez le hachage d'un mot de passe associé à une chaîne aléatoire connue (pour empêcher les attaques Rainbow) et stockez ce hachage dans la base de données.
Le problème est que si un attaquant obtient un dump de la base de données, il peut très bien 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 résoudre ce problème, l'algorithme bcrypt peut être utilisé. Il est conçu pour être lent, de sorte que l'attaquant sera considérablement ralenti s'il attaque un système utilisant bcrypt. Récemment scrypt a fait quelques gros titres et est considéré par certains comme plus efficace que bcrypt mais je ne connais pas d'implémentation .Net.
Mise à jour:
Les temps ont changé, nous avons un gagnant SHA3. Je recommanderais d'utiliser keccak (aka SHA ) gagnant du concours SHA3.
Réponse originale:
Par ordre du plus faible au plus fort, je dirais:
- RIPEMD BROKEN, ne devrait jamais être utilisé comme on peut le voir dans ce pdf
- MD-5 BROKEN, ne devrait jamais être utilisé, peut être cassé en 2 minutes avec un ordinateur portable
- SHA-1 BROKEN, ne devrait jamais être utilisé, cassé en principe, les attaques s'améliorent de semaine en semaine
- SHA-2 WEAK, sera probablement cassé dans les prochaines années. Quelques faiblesses ont été trouvées. Notez que généralement, plus la taille de la clé est élevée, plus la fonction de hachage est dure à casser. Bien que la taille de la clé = la force ne soit pas toujours vraie, elle l'est surtout. Donc, SHA-256 est probablement plus faible que SHA-512.
- Skein AUCUN FAIBLESSES CONNUES, est candidat à SHA- . C'est assez nouveau et donc non testé. Il a été implémenté dans de nombreuses langues.
- MD6 AUCUN FAIBLESSES CONNUES, est un autre candidat à SHA-3. Probablement plus fort que Skien, mais plus lent sur les machines simple cœur. Comme Skien, il n’a pas été testé. Certains développeurs soucieux de la sécurité l’utilisent, dans rôles critiques .
Personnellement, j'utiliserais MD6, car on ne peut jamais être trop paranoïaque. Si la vitesse est une préoccupation réelle, 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 efficace. 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 d'interception.
Le type 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 transit et que la sécurité ne vous préoccupe pas, optez pour une solution rapide et rapide. 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'elles ne sont pas falsifiées, optez pour les durs à usurper et à ralentir.
Je voudrais préciser (avant que md5 ne se déchire) que j’utilise encore md5 à grande échelle malgré son écrasement écrasant pour beaucoup de crypto.
Tant que vous ne vous souciez pas de la protection contre les collisions (vous pouvez toujours utiliser md5 dans un hmac également) et que vous voulez la vitesse (vous souhaitez parfois un hash 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écurisé que SHA-3. Il est également implémenté par plusieurs applications logicielles , y compris WinRar.
Je ne suis pas un expert dans ce genre de choses, mais je suis au courant avec la communauté de la sécurité et beaucoup de gens là-bas considèrent que le hash md5 est cassé. Je dirais que celui à utiliser dépend de la sensibilité des données et de l'application spécifique. Vous pouvez peut-être vous en tirer avec un hachage légèrement moins sécurisé tant que la clé est bonne et solide.
Voici mes suggestions pour vous:
- Vous devriez probablement oublier MD5 si vous prévoyez des attaques. Il y a beaucoup de tables Rainbow 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.
- Utilisez un sel si vous le pouvez. Le fait d'inclure la longueur du message dans le message peut rendre très difficile la réalisation d'une collision de hachage utile.
- En règle générale, plus de bits signifie moins de collisions (selon le principe du casier), plus lent et peut-être plus sûr (sauf si vous êtes un génie des mathématiques capable de détecter des vulnérabilités).
Voir ici pour un article détaillant un algorithme pour créer des collisions md5 en 31 secondes avec un ordinateur de bureau Intel P4.