Réseaux et infrastructures

Particuliers et entreprises

Collisions de hachage

Birthday attack — Attaque des anniversaires

Le paradoxe des anniversaires explique comment rechercher deux données différentes ayant la même empreinte numérique.

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

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

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 transforme des données en une empreinte de longueur fixe. Deux contenus différents peuvent donner la même empreinte : c’est une collision. Une bonne fonction cryptographique rend la recherche d’une telle paire impraticable à l’échelle prévue.

Le paradoxe des anniversaires aide à comprendre cette recherche. Dans un groupe de 23 personnes, la probabilité que deux partagent leur jour d’anniversaire dépasse 50 %, si l’on suppose 365 jours équiprobables et des naissances indépendantes. On compare toutes les paires du groupe, soit 253 paires, et non chacun à une date fixée à l’avance.

L’attaque des anniversaires applique cette idée aux empreintes : multiplier les candidats multiplie les paires possibles. Elle cherche deux contenus qui coïncident, sans imposer leur empreinte. Elle ne retrouve pas un mot de passe et ne déchiffre pas un fichier.

Repère historique : en 2017, Google et le CWI ont publié deux PDF différents ayant la même empreinte SHA-1, dans le cadre de la recherche SHAttered. Cette démonstration exploite des faiblesses propres à SHA-1 pour accélérer la recherche ; ce n’est pas une simple application du 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

Recensez où une empreinte déclenche une validation, une signature ou une fusion de fichiers. Vérifiez l’algorithme et la longueur réellement comparée, puis corrigez les usages fragiles en conservant une référence de confiance.

Le détail qui change toutUne idée reçue à corriger

Trouver deux contenus qui partagent une empreinte ne permet pas automatiquement de modifier un document déjà imposé en conservant 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 ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Non. Quatre caractères hexadécimaux ne représentent que 16 bits : de nombreux contenus peuvent partager cette étiquette. Comparez l’empreinte complète et, si nécessaire, les octets des fichiers. Pour savoir d’où ils viennent, il faut aussi une source de confiance ; l’égalité d’un hash ne prouve pas l’identité de l’auteur.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

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

Les deux textes produisent des empreintes SHA-256 différentes, mais les quatre premiers caractères hexadécimaux sont identiques : 60b9. Un caractère hexadécimal représente quatre bits. Le service fictif compare seulement 16 bits et déclare donc, à tort, qu’il s’agit du même document. Il y a collision sur la valeur tronquée, pas sur SHA-256 complet.

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.

Éléments à croiser

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.

Limites de l’interprétation

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

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

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 ?

Formulez votre décision et l’élément qui la justifie 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

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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 qualifier votre situation et être orienté : 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