Réseaux et infrastructures

Particuliers et entreprises

Collisions de hachage

Birthday attack — Attaque des anniversaires

Deux contenus différents peuvent avoir la même empreinte : le paradoxe des anniversaires aide à comprendre cette recherche.

Révision éditoriale : 27 octobre 2026Comprendre : 3 min · Cas technique et détails : 5 min

Je pense être concerné : que faire ?

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Un service classe des documents à partir d’une empreinte numérique très courte. Une personne prépare de nombreuses variantes jusqu’à obtenir deux fichiers différents portant la même empreinte. Si le service considère cette égalité comme une preuve que les fichiers sont identiques, il peut confondre les documents. Ce scénario pédagogique suppose un contrôle insuffisant ; toute collision n’aboutit pas à une falsification exploitable.

Comment cela fonctionne

Une fonction de hachage calcule une empreinte de longueur fixe à partir de données. Deux contenus différents peuvent avoir la même empreinte : on parle de collision. Une bonne fonction cryptographique rend la recherche de ces paires impraticable à l’échelle prévue.

Le paradoxe des anniversaires aide à comprendre pourquoi les paires comptent. Avec 23 personnes, on dépasse 50 % de probabilité que deux aient leur anniversaire le même jour, en supposant 365 jours aussi probables et des naissances indépendantes. Le groupe contient 253 paires à comparer. On ne cherche pas une personne née à une date choisie à l’avance.

L’attaque des anniversaires applique ce raisonnement aux empreintes. Plus on essaie de contenus, plus les paires possibles se multiplient. On cherche deux contenus ayant la même empreinte, quelle qu’elle soit. Cette recherche ne retrouve pas un mot de passe et ne déchiffre pas un fichier.

En 2017, Google et le CWI ont publié, avec le projet SHAttered, deux PDF différents ayant la même empreinte SHA-1. Ils ont exploité des faiblesses propres à SHA-1 pour accélérer la recherche. Leur démonstration dépasse donc le seul calcul générique des anniversaires.

Comment le piège fonctionne

Des contenus différents sont préparés
Chaque candidat reçoit une empreinte.
Deux empreintes coïncident
La recherche porte sur toutes les paires possibles.
Le service doit encore être trompé
L’effet dépend de ce qu’il vérifie et accepte.

Ce que vous pouvez faire

Vos premiers réflexes

Pour contrôler un fichier, utilisez l’empreinte complète publiée par une source officielle pour la même version. Deux codes abrégés identiques ne suffisent pas à conclure. Si un document paraît différent malgré le contrôle, conservez-le et signalez l’écart.

Si vous êtes responsable du service ou de l’organisation

Repérez les contrôles où une empreinte sert à valider, signer ou fusionner des fichiers. Vérifiez l’algorithme et la longueur effectivement comparée. Corrigez les contrôles fragiles en gardant une référence fiable.

Un point à vérifierUne idée reçue à corriger

Trouver deux contenus avec la même empreinte ne signifie pas qu’on peut modifier un document choisi à l’avance tout en gardant son empreinte.

À vous de décider

Deux fichiers portent les quatre mêmes premiers caractères d’une empreinte SHA-256. Pouvez-vous conclure qu’ils sont identiques ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. Les quatre caractères ne représentent que 16 bits. Des contenus différents peuvent partager ce début d’empreinte. Comparez l’empreinte complète et, si nécessaire, les octets. Pour vérifier la provenance, il faut aussi une source fiable : deux empreintes égales ne prouvent pas qui a créé les fichiers.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Deux documents se confondent quand le contrôle ne garde que 16 bits

Les deux textes ont des empreintes SHA-256 différentes, mais leurs quatre premiers caractères sont identiques : 60b9. Chaque caractère hexadécimal représente quatre bits. Le service fictif ne compare donc que 16 bits et prend à tort les textes pour un même document. La collision concerne cette valeur raccourcie, pas l’empreinte SHA-256 complète.

Cette petite taille permet de comprendre le paradoxe sans simuler une attaque réaliste contre une fonction moderne. Pour 65 536 valeurs possibles, le seuil d’environ 50 % se situe vers 301 candidats indépendants. Une paire peut apparaître avant ou après : ce seuil n’est pas un nombre d’essais garanti. Les deux textes du cas sont libres ; aucun document de référence n’était imposé à l’avance.

L’erreur décisive est d’utiliser une étiquette courte comme une preuve d’égalité. Si seule l’interface affiche quatre caractères et que le serveur compare les 256 bits complets, le même affichage ne suffit pas à tromper la vérification. Il faut donc examiner la configuration et la décision effective, pas seulement une capture d’écran.

Une collision ne prouve pas la méthode employée pour la trouver. Dans un incident réel, un défaut de comparaison, une normalisation des entrées ou une collision accidentelle peuvent aussi expliquer le résultat. Aucun élément de ce cas ne démontre le vol d’un secret, une signature falsifiée ou une collision sur SHA-256 complet.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape

CandidatsDeux textes distincts

HachageSHA-256 complet

ServiceComparaison de 16 bits

AnalysteOctets et décision

Action
Calcul des deux empreintes
Candidats vers Hachage
Trace entrées UTF-8 distinctes
Réponse
Valeurs complètes disponibles
Hachage vers Service
Trace sha256_A et sha256_B
Action sur place
Conservation de quatre caractères
Service
Trace compared_bits=16
Action sur place
Assimilation erronée des objets
Service
Trace legacy_decision=same_document
Action
Examen du contrôle appliqué
Service vers Analyste
Trace reason=short_digest_equal
Action
Comparaison indépendante des contenus
Candidats vers Analyste
Trace bytes_equal=false
Refus / blocage
Refus de l’équivalence après correction
Analyste vers Service
Trace corrected_decision=distinct_documents

Comment repérer cette attaque

Indices à rechercher

Deux fichiers dont les octets diffèrent partagent la même empreinte utilisée par le service.
Un contrôle de sécurité repose sur MD5, SHA-1 ou seulement quelques caractères d’une empreinte.
Un service assimile des documents sur la seule égalité d’un identifiant court, sans autre vérification.

Rechercher les décisions d’équivalence prises sur des empreintes courtes, puis comparer les octets et les empreintes complètes des objets préservés. Vérifier dans le code ou la configuration si la troncature concerne seulement l’affichage ou réellement le contrôle.

Quelles informations comparer

Relier chaque empreinte au fichier exact et à la version du service ayant pris la décision. Comparer ensuite la règle annoncée à la longueur effectivement utilisée : il faut prouver l’assimilation des deux objets, pas seulement l’égalité de deux libellés.

Ce que ces indices ne permettent pas de conclure

Une collision sur un identifiant court peut être accidentelle. Elle ne prouve ni une attaque des anniversaires ni une collision sur la fonction complète. Les recherches réalisées hors ligne restent invisibles dans les seuls journaux de la cible.

Comment réagir

Suspendre les rapprochements litigieux et préserver les objets ainsi que l’ancienne configuration. Corriger la comparaison, reconstruire les références depuis des originaux vérifiés et réexaminer les fusions ou validations antérieures concernées. Changer d’algorithme sans corriger une comparaison limitée à 16 bits laisserait le problème en place.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

Vérifier que deux fichiers différents partageant une étiquette courte restent distingués par le contrôle corrigé.
Confirmer qu’un fichier inchangé est toujours reconnu et que l’interface abrégée n’impose pas sa longueur au serveur.
Contrôler les décisions passées et la provenance des références avant de déclarer les documents authentiques.

À vous de raisonner

Un document est fixé à l’avance et son SHA-256 complet est vérifié. Trouver une paire quelconque partageant 16 bits permet-il de lui substituer un autre document ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non. La paire ne porte que sur une valeur tronquée et ne cible pas le document imposé. Il faudrait trouver un autre contenu ayant exactement son empreinte complète : c’est le problème de seconde préimage. Le gain générique des anniversaires concerne la recherche d’une paire libre, pas cette substitution.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

compared_bits: Champ pédagogique décrivant la longueur du contrôle réel ; il n’existe pas automatiquement dans les journaux d’un logiciel.
full_digest_equal: Comparaison des SHA-256 complets : false distingue ici une collision de préfixes d’une collision sur 256 bits.
legacy_decision: Décision fictive du service vulnérable ; elle doit être établie par les traces et la configuration dans un cas réel.

Comparaison d’une empreinte courte et des valeurs complètes

Journal

Reconstitution pédagogique d’un service fictif, pas journal d’incident. Les SHA-256 sont calculés sur les chaînes UTF-8 indiquées, chacune terminée par un seul saut de ligne LF. Les autres champs décrivent le scénario.

scope=pedagogical service=document-demo
input_A="Pièce pédagogique 68\n"
input_B="Pièce pédagogique 269\n"
algorithm=SHA-256 compared_bits=16
sha256_A=60b9567ab2ffe6688dfb21cea11bae33e21c7cdc47d09c013dfc23141bdd139f
sha256_B=60b973d3d1e94e71376cd9dab75c98d8e8a74bd0ef244dc2a05d3f30c7c518c6
short_A=60b9 short_B=60b9
bytes_equal=false full_digest_equal=false
legacy_decision=same_document reason=short_digest_equal
corrected_decision=distinct_documents

Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

Fichiers préservés — comparaison et empreintes complètes
Où les trouver
Sur des copies de travail des fichiers conservés, dans l’environnement d’analyse autorisé. Calculer les empreintes complètes avec un outil fiable, puis comparer les octets si une égalité mérite vérification.
Quoi relever
Préserver les deux fichiers sans conversion, noter leur provenance et comparer leurs octets ainsi que leurs SHA-256 complets. Conserver l’outil, sa version, l’encodage et les fins de ligne lorsqu’il s’agit de textes.
Accès et prérequis
Accès aux originaux ou à des copies dont la provenance est documentée. Préciser l’algorithme, la longueur et toute transformation ; un recalcul actuel ne prouve pas quel fichier le service a traité auparavant.
Documentation : Fichiers préservés — comparaison et empreintes complètes
Service concerné — audit et historique à vérifier
Où les trouver
Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
Quoi relever
Demander la configuration ou le code du contrôle, la longueur effectivement comparée, l’identifiant des objets et les décisions enregistrées. Une étiquette abrégée à l’écran ne révèle pas à elle seule la vérification du serveur.
Accès et prérequis
Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Pour l’équipe qui exploite le service

Conservez les deux fichiers, leurs empreintes complètes, l’algorithme utilisé et leur provenance avant tout remplacement.
Suspendez la validation litigieuse et demandez au responsable du service de vérifier les fichiers octet par octet et les règles de comparaison.
Corrigez le contrôle puis réexaminez les documents concernés depuis une référence fiable : recalculer une empreinte ne garantit pas leur authenticité passée.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

NIST — fonctions de hachage et résistances cryptographiques — csrc.nist.gov
NIST — définition d’une fonction de hachage cryptographique — csrc.nist.gov
Google et CWI — annonce de la collision SHA-1 SHAttered (2017) — security.googleblog.com