Skip to content
Omnikalc

Calculer la probabilité de collision d'un hachage ou d'identifiants

Estimez la probabilité que deux identifiants aléatoires ou empreintes parmi n se ressemblent pour un nombre de bits donné, combien d'éléments donnent 50 % de risque et combien le maintiennent sous un sur un million.

Mis à jour le
Vos paramètres
bits

Valeur hors limites

Valeur hors limites

Résultats

Probabilité d'au moins une collision

2,674 %

Plus d'un sur un million : acceptable seulement si les collisions sont sans gravité ou détectées
Nombre attendu de paires en collision
0,02711
Éléments pour 50 % de risque de collision
5 056 894 494
Éléments pour rester sous un risque sur un million
6 074 001
Valeurs possibles, en puissance de dix (10^x)
19,27

Le paradoxe des anniversaires en informatique

Combien faut-il de personnes dans une pièce pour que deux d’entre elles aient une chance sur deux de partager leur anniversaire ? Seulement 23, bien moins que les 365 jours de l’année. La même surprise vaut pour les empreintes de hachage, les identifiants aléatoires et les sommes de contrôle : les collisions apparaissent bien avant que l’espace des valeurs possibles soit rempli. C’est la borne des anniversaires.

La formule

Avec b bits, il existe 2^b valeurs possibles. Pour n éléments aléatoires, le nombre attendu de paires en collision vaut n(n − 1) ÷ 2^(b+1), et la probabilité d’au moins une collision est environ :

p ≈ 1 − e^(−n² ÷ 2^(b+1))

Le nombre d’éléments qui donne 50 % de risque vaut environ 1,1774 × 2^(b/2) : la racine carrée de l’espace, et non l’espace lui-même.

Exemple

Un milliard d’identifiants aléatoires de 64 bits : n² ÷ 2^65 ≈ 0,0271, donc p ≈ 2,7 %. Les 50 % sont atteints vers 5,06 milliards d’éléments, et rester sous un risque sur un million limite à environ 6 millions d’éléments.

Bits 50 % de collision après Risque d’un sur un million après
32 77 000 93
64 5,1 milliards 6,1 millions
128 (l’UUID v4 en a 122) 2,2 × 10¹⁹ 2,6 × 10¹⁶
256 4 × 10³⁸ 4,8 × 10³⁵

Conclusions pratiques

  • Les hachages de 32 bits (CRC-32, identifiants courts) entrent vite en collision : ne les utilisez jamais comme clés uniques.
  • Des identifiants aléatoires de 64 bits conviennent pour des millions de lignes, pas pour des milliards.
  • Un UUID v4 compte 122 bits aléatoires : il en faudrait environ 2,7 milliards de milliards pour une chance sur deux.
  • Tronquer un SHA-256 à 8 caractères hexadécimaux ne laisse que 32 bits.

Collisions accidentelles et collisions provoquées

Ces chiffres supposent des valeurs aléatoires. Un attaquant qui cherche une collision a lui aussi besoin d’environ 2^(b/2) essais : c’est pourquoi l’ANSSI recommande des fonctions de hachage d’au moins 256 bits pour une sécurité de 128 bits. Les algorithmes cassés comme MD5 et SHA-1 permettent des collisions bien plus vite que la borne des anniversaires.

Questions fréquentes

Pourquoi les collisions arrivent-elles si tôt ?

Chaque nouvel élément peut entrer en collision avec tous ceux déjà stockés : le nombre de paires croît comme n au carré. Les collisions deviennent probables vers la racine carrée du nombre de valeurs possibles.

Deux UUID peuvent-ils être identiques ?

En théorie oui, mais un UUID version 4 compte 122 bits aléatoires. Il en faudrait environ 2,7 milliards de milliards pour une chance sur deux d'un seul doublon : avec un bon générateur aléatoire, cela n'arrive pas en pratique.

Un hachage de 32 bits suffit-il comme clé de cache ?

Seulement pour de petits ensembles. Avec 32 bits, une collision devient probable vers 77 000 éléments : le cache doit donc comparer la clé complète ou utiliser un hachage de 64 bits ou plus.

Cela s'applique-t-il aux hachages cryptographiques ?

Oui pour les collisions accidentelles, et un attaquant a lui aussi besoin d'environ 2^(b/2) essais contre une fonction saine. C'est pourquoi on utilise SHA-256 pour une sécurité de 128 bits.

Ce calculateur vous a-t-il été utile ?

Merci pour votre avis !

Résultats indicatifs fournis à titre d'information. Ils ne remplacent pas l'avis d'un professionnel.