Collision de hachage dans git
Que se passerait-il si j'avais une collision de hachage en utilisant git?
Par exemple. Je parviens à valider deux fichiers avec la même somme de contrôle sha1, le remarquerais-je ou corromprait-il l'un des fichiers?
Est-ce que git pourrait être amélioré pour vivre avec ça, ou devrais-je changer pour un nouvel algorithme de hachage?
(S'il vous plaît ne pas dévier cette question en discutant à quel point c'est peu probable - Merci)
Cueillette des atomes sur 10 lunes
Un hachage SHA-1 est une chaîne de 40 caractères hexadécimaux ... soit 4 bits par caractère fois 40 ... 160 bits. Nous savons maintenant que 10 bits correspondent à environ 1 000 (1024 pour être exact), ce qui signifie qu'il y a 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 différents types de hachages SHA-1 ... 1048.
Quel est cet équivalent de? Eh bien, la Lune est composée d'environ 1047 des atomes. Donc, si nous avons 10 lunes ... et que vous en choisissez une au hasard atom sur une de ces lunes ...), puis continuez et choisissez une image aléatoire atom sur eux encore ... alors la probabilité que vous choisissiez le même atom deux fois, est la probabilité que deux commits git aient le même hachage SHA-1.
En développant cela, nous pouvons poser la question ...
De combien de commits avez-vous besoin dans un référentiel avant de vous inquiéter des collisions?
Cela concerne ce qu'on appelle les "attaques d'anniversaire", qui à leur tour font référence au "paradoxe d'anniversaire" ou "problème d'anniversaire", qui stipule que lorsque vous choisissez au hasard dans un ensemble donné, vous avez étonnamment besoin de peu de choix avant d'être plus probable avoir pris quelque chose deux fois. Mais "étonnamment peu" est un terme très relatif ici.
Wikipedia a n tableau sur la probabilité de collisions Birthday Paradox . Il n'y a pas d'entrée pour un hachage de 40 caractères. Mais une interpolation des entrées pour 32 et 48 caractères nous amène dans la plage de 5 * 1022 git s'engage pour une probabilité de 0,1% d'une collision. C’est cinquante mille milliards de milliards d’engagements différents, ou cinquante Zettacommits , avant même d’avoir atteint une chance de 0,1% d’avoir une collision.
La somme en octets des hachages pour ces commits constituerait plus de données que toutes les données générées sur Terre pendant un an, ce qui signifie que vous auriez besoin de produire du code plus rapidement que de la vidéo diffusée par YouTube. Bonne chance avec ça. :RÉ
Le but de ceci est que, sauf si quelqu'un cause délibérément une collision, la probabilité qu'une collision se produise au hasard est si petite que vous pouvez ignorer ce problème
"Mais quand une collision fait se produit, alors que se passe-t-il réellement?"
Ok, supposons que l'improbable se produise, ou supposons que quelqu'un réussisse à personnaliser ne collision délibérée de hachage SHA-1 . Qu'est-ce qui se passe ensuite?
Dans ce cas, il y a ne excellente réponse lorsque quelqu'un a expérimenté dessus . Je vais citer cette réponse:
- Si un blob existe déjà avec le même hash, vous ne recevrez aucun avertissement. Tout semble aller pour le mieux, mais si vous poussez, si quelqu'un clone ou si vous revenez en arrière, vous perdrez la dernière version (conformément à ce qui est expliqué ci-dessus).
- Si un objet tree existe déjà et que vous créez un blob avec le même hachage: tout semblera normal, jusqu'à ce que vous essayiez de Push ou que quelqu'un clone votre référentiel. Ensuite, vous verrez que le repo est corrompu.
- Si un objet de validation existe déjà et que vous créez un blob avec le même hash: identique à # 2 - corrompu
- Si un blob existe déjà et que vous créez un objet commit avec le même hachage, il échouera lors de la mise à jour du "ref".
- Si un blob existe déjà et que vous créez un objet arbre avec le même hachage. Cela échouera lors de la création du commit.
- Si un objet d'arborescence existe déjà et que vous créez un objet de validation avec le même hachage, il échouera lors de la mise à jour du "ref".
- Si un objet d'arborescence existe déjà et que vous en créez un avec le même hachage, tout vous semblera correct. Mais lorsque vous vous engagez, tout le référentiel fera référence à la mauvaise arborescence.
- Si un objet de validation existe déjà et que vous créez un objet de validation avec le même hachage, tout semblera correct. Mais lorsque vous validez, le commit ne sera jamais créé et le pointeur HEAD sera déplacé vers un ancien commit.
- Si un objet de validation existe déjà et que vous créez un objet d'arborescence avec le même hachage, il échouera lors de la création de la validation.
Comme vous pouvez sembler, certains cas ne sont pas bons. En particulier, les cas n ° 2 et n ° 3 gâchent votre référentiel. Cependant, il semble que la faute reste dans ce référentiel et l'attaque/l'improbabilité bizarre ne se propage pas à d'autres référentiels.
De plus, il semble que la question des collisions délibérées soit reconnue comme une menace réelle, et par exemple GitHub prend des mesures pour la prévenir .
Si deux fichiers ont la même somme de hachage dans git, ces fichiers seront considérés comme identiques. Dans le cas absolument improbable où cela se produirait, vous pourriez toujours revenir en arrière d'un commit et modifier quelque chose dans le fichier afin qu'ils ne se collent plus ...
Il n'est pas vraiment possible de répondre à cette question avec le bon "mais" sans expliquer aussi pourquoi ce n'est pas un problème. Ce n'est pas possible de faire cela sans vraiment avoir une bonne emprise sur ce qu'est un hash. C'est plus compliqué que les cas simples auxquels vous pourriez avoir été exposé dans un programme CS.
Il y a un malentendu fondamental de la théorie de l'information ici. Si vous réduisez une grande quantité d'informations en une quantité inférieure en supprimant une certaine quantité (un hachage, par exemple), il existe un risque de collision directement lié à la longueur des données. Plus les données sont courtes, moins elles le seront. Maintenant, la grande majorité des collisions seront du charabia, ce qui les rendra beaucoup plus susceptibles de se produire réellement (vous ne vérifieriez jamais en charabia ... même une image binaire est quelque peu structurée). En fin de compte, les chances sont faibles. Pour répondre à votre question, oui, git les traitera de la même manière, changer l'algorithme de hachage ne vous aidera pas, cela nécessitera une "deuxième vérification", mais au final, vous aurez besoin d'autant de données de "vérification supplémentaire" comme la longueur des données est sûre à 100% ... gardez à l'esprit que vous seriez 99,99999 ... avec un très grand nombre de chiffres ... sûr avec une simple vérification comme celle que vous décrivez. Les SHA-x sont des hachages cryptographiquement puissants, ce qui signifie qu'il n'est généralement pas difficile de créer intentionnellement deux ensembles de données source TRES SIMILAIRES l'un à l'autre et qui ont le même hachage. Un bit de changement dans les données doit créer plus d'un bit (de préférence autant que possible) dans la sortie de hachage, ce qui signifie également qu'il est très difficile (mais pas tout à fait impossible) de revenir au hash complet. collisions et ainsi extraire le message original de cet ensemble de collisions - presque toutes seront du charabia, et parmi celles qui ne le sont pas, il reste encore un nombre considérable à filtrer si la longueur du message est trop longue. L'inconvénient d'un chiffrement est qu'ils sont lents à calculer ... en général.
Alors, qu'est-ce que tout cela signifie alors pour Git? Pas tant. Les hachages sont si rarement effectués (par rapport à tout le reste) que leur pénalité de calcul est globalement faible pour les opérations. Les chances de rencontrer une paire de collisions sont si faibles que ce n'est pas une chance réaliste de se produire et de ne pas être détecté immédiatement (votre code cesserait probablement de fonctionner brusquement), ce qui permettra à l'utilisateur de résoudre le problème (sauvegarder une révision, et effectuez le changement à nouveau, et vous obtiendrez certainement un hachage différent à cause du changement d'heure, qui nourrit également le hachage en git). Il est plus probable que cela pose un réel problème pour vous si vous stockez des fichiers binaires arbitraires dans git, ce qui n'est pas vraiment ce que son modèle d'utilisation principale est. Si vous voulez faire cela ... vous feriez probablement mieux d'utiliser une base de données traditionnelle.
Ce n’est pas une erreur de penser à cela - c’est une bonne question que beaucoup de gens qualifient simplement de "tellement improbable que cela ne vaut pas la peine d’y penser" - mais c’est vraiment un peu plus compliqué que cela. Si cela se produit, il devrait être très facilement détectable, ce ne sera pas une corruption silencieuse dans un flux de travail normal.
Est-ce que git pourrait être amélioré pour vivre avec ça, ou devrais-je changer pour un nouvel algorithme de hachage?
Les collisions sont possibles pour tous les algorithmes de hachage. Par conséquent, le fait de modifier la fonction de hachage n’exclut pas le problème, mais le rend moins susceptible de se produire. Vous devriez donc choisir une très bonne fonction de hachage (SHA-1 l'est déjà, mais vous avez demandé à ne pas être informé :)
Vous pouvez voir une bonne étude dans " Comment Git gérerait-il une collision SHA-1 sur un blob? ".
Depuis une collision SHA1 est maintenant possible (comme je référence dans cette réponse avec shattered.io ), sachez que Git 2.13 (T2 2017) améliorera/atténuera la situation actuelle avec une variante de "tentative de détection de collision" de implémentation SHA-1 de Marc Stevens (CWI) et Dan Shumow (Microsoft) =.
Voir commit f5f5e7f , commit 8325e4 , commit c0c2006 , commit 45a574e , commit 28dc98e (16 mars 2017) par Jeff King (peff) .
(Fusion par Junio C Hamano - gitster - dans commit 48b369 , 24 mars 2017)
Makefile: makeDC_SHA1le défautNous avions l'habitude d'utiliser l'implémentation SHA1 de la bibliothèque OpenSSL par défaut.
Alors que nous essayons de faire attention aux attaques de collision après la récente annonce "brisée", changez la valeur par défaut pour encourager les utilisateurs à utiliser plutôt la mise en oeuvre de DC_SHA1.
Ceux qui souhaitent utiliser l’implémentation d’OpenSSL peuvent le demander explicitement parOPENSSL_SHA1=YesPleaselorsque vous exécutez "make".Nous n'avons pas réellement de collision Git-objet. Le mieux que nous puissions faire est donc d'exécuter l'un des fichiers PDF fragmentés dans test-sha1. Cela devrait déclencher le contrôle de collision et mourir.
Git pourrait-il être amélioré pour vivre avec cela ou devrais-je passer à un nouvel algorithme de hachage?
Mise à jour déc. 2017 avec Git 2.16 (T1 2018): cet effort pour soutenir une alternative SHA est en cours: voir " Pourquoi Git n'utilise-t-il pas un SHA plus moderne? ".
Vous pourrez utiliser un autre algorithme de hachage: SHA1 n'est plus le seul pour Git.
Git 2.18 (T2 2018) documente ce processus.
Voir commit 5988eb6 , commit 45fa195 (26 mars 2018) par var Arnfjörð Bjarmason (avar) .
(Fusionné par Junio C Hamano - gitster - dans commit d877975 , 11 avril 2018)
doc
hash-function-transition: clarifie ce que signifie SHAtteredEssayez de clarifier ce que l’attaque SHAttered signifie en pratique pour Git.
La version précédente du texte ne mentionnait nullement le fait que Git disposait déjà d'une atténuation pour cette attaque spécifique, qui, selon les chercheurs de SHAttered, détectera les attaques par collision cryptanalytique.Je me suis peut-être trompé dans certaines nuances, mais pour autant que je sache, ce nouveau texte résume avec précision la situation actuelle de SHA-1 in git. C'est à dire. git n'utilise plus vraiment SHA-1, il utilise Hardened-SHA-1 (il arrive juste de produire les mêmes sorties 99.99999999999 ... % du temps).
Ainsi, le texte précédent affirmait incorrectement que:
[...] En conséquence [de SHAttered], SHA-1 ne peut plus être considéré comme étant cryptographiquement sécurisé [...]
Ce n'est pas le cas. Nous avons une atténuation contre SHAttered, cependant, nous considérons qu'il est prudent de progresser vers un
NewHashsi de futures vulnérabilités de SHA-1 ou de Hardened-SHA-1 se présentaient.
Donc, le nouvelle documentation se lit maintenant:
Git v2.13.0 et ultérieur ont par la suite migré vers une implémentation SHA-1 renforcée, par défaut, qui n'est pas vulnérable à l'attaque SHAttered.
Ainsi, Git a en effet déjà migré vers un nouveau hachage qui n'est pas SHA-1 et ne partage pas ses vulnérabilités. Sa nouvelle fonction de hachage produit exactement la même sortie pour toutes les entrées connues, à l'exception de deux PDF publiés par SHAttered. chercheurs, et la nouvelle implémentation (écrite par ces chercheurs) prétend détecter les futures attaques de collision cryptanalytique.
Quoi qu’il en soit, il est considéré prudent de remplacer toute variante de SHA-1 par un nouveau hachage. Rien ne garantit que les futures attaques sur SHA-1 ne seront pas publiées à l'avenir, et ces attaques pourraient ne pas avoir d'atténuation viable.
Si SHA-1 et ses variantes devaient vraiment être brisés, la fonction de hachage de Git ne pourrait plus être considérée comme étant cryptographiquement sécurisée. Cela aurait un impact sur la communication des valeurs de hachage, car nous ne pouvions pas nous attendre à ce qu'une valeur de hachage donnée représente la bonne version connue du contenu que le locuteur avait prévu.
Remarque: le même document maintenant (Q3 2018, Git 2.19) fait explicitement référence au "nouveau hachage" comme SHA-256 : voir " Pourquoi Git n’utilise-t-il pas un SHA plus moderne? ".
Google affirme maintenant que la collision SHA-1 est possible sous certaines conditions préalables: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
Puisque git utilise SHA-1 pour vérifier l’intégrité des fichiers, cela signifie que l’intégrité des fichiers dans git est compromise.
OMI, git devrait certainement utiliser un meilleur algorithme de hachage, car une collision délibérée est maintenant possible.
Une collision de hasch est tellement improbable qu'elle est époustouflante! Les scientifiques du monde entier s’efforcent d’en réaliser un, mais ne l’ont pas encore fait. Pour certains algorithmes tels que MD5, ils ont réussi, cependant.
Quelles sont les chances?
SHA-256 a 2 ^ 256 hachages possibles. C'est à peu près 10 ^ 78 . Ou pour être plus graphique, les chances d'une collision sont à peu près
1: 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
La chance de gagner à la loterie est d'environ 1: 14 Mio . Le risque de collision avec SHA-256 équivaut à gagner à la loterie 11 jours consécutifs !
Explication mathématique: 14 000 0 ^ 11 ~ 2 ^ 256
De plus, le nivers a environ 10 ^ 80 atomes. C'est juste 100 fois plus qu'il n'y a de combinaisons SHA-256.
Collision MD5 réussie
Même pour MD5 , les chances sont minimes. Cependant, les mathématiciens ont réussi à créer une collision:
d131dd02c5e6eec4 693d9a0698aff95c 2fcab58712467eab 4004583eb8fb7f89 55ad340609f4b302 83e488832571415a 085125e8f7cdc99f d91dbdf280373c5b D8823e3156348f5b ae6dacd436c919c6 dd53e2b487da03fd 02396306d248cda0 E99f33420f577ee8 ce54b67080une80d1e c69821bcb6a88393 96f9652b6ff72a70
a le même MD5 que
d131dd02c5e6eec4 693d9a0698aff95c 2fcab5712467eab 4004583eb8fb7f89 55ad340609f4b302 83e4888325f1415a 085125e8f7cdc99f d91dbd7280373c5b D8823e3156348f5b ae6dacd436c919c6 dd53e23487da03fd 02396306d248cda0 E99f33420f577ee8 ce54b67080280d1e c69821bcb6a88393 96f965uneb6ff72a70
Cela ne signifie pas que MD5 est moins sûr maintenant que son algorithme est fissuré. Vous pouvez créer des collisions MD5 à dessein, mais le risque d’une collision MD5 accidentelle est toujours de 2 ^ 128, ce qui est toujours beaucoup.
Conclusion
Vous n'avez pas à vous soucier des collisions. Les algorithmes de hachage constituent le deuxième moyen le plus sûr de vérifier la similarité des fichiers. Le seul moyen plus sûr est une comparaison binaire.
J'ai récemment trouvé un message du 2013-04-29 dans un groupe de discussion BSD à
http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html
où l'affiche prétend:
Une fois, je suis tombé sur une collision de hachage, avec git rebase.
Malheureusement, il ne fournit aucune preuve de sa réclamation. Mais peut-être aimeriez-vous essayer de le contacter et de lui poser des questions sur cet incident présumé.
Mais à un niveau plus général, en raison de l’attaque anniversaire, les chances d’une collision de hachage SHA-1 sont de 1 sur 1 (1, 8).
Cela semble beaucoup et est certainement bien plus que le nombre total de versions de fichiers individuels présents dans tous les référentiels Git du monde combinés.
Cependant, cela ne s'applique qu'aux versions qui restent réellement dans l'historique des versions.
Si un développeur s'appuie beaucoup sur le changement de base, chaque fois qu'une base est exécutée pour une branche, tous les commits de toutes les versions de cette branche (ou de la partie de la branche redéfinie) reçoivent de nouveaux hachages. Il en va de même pour chaque fichier modifié avec "git filter-branch". Par conséquent, "rebase" et "filter-branch" peuvent être de gros multiplicateurs pour le nombre de hachages générés au fil du temps, même s'ils ne sont pas tous conservés: ), la branche d'origine est jetée.
Mais si la collision se produit pendant la branche de rebase ou le filtre, elle peut toujours avoir des effets néfastes.
Une autre chose à faire serait d’estimer le nombre total d’entités hachées dans les dépôts git et de voir à quelle distance elles se trouvent de pow (2, 80).
Disons que nous avons environ 8 milliards de personnes, et que toutes exécuteraient git et conserveraient leur version dans 100 référentiels git par personne. Supposons en outre que le référentiel moyen compte 100 validations et 10 fichiers, et qu'un seul de ces fichiers change par validation.
Pour chaque révision, nous avons au moins un hachage pour l'objet arbre et l'objet commit lui-même. Avec le fichier modifié, nous avons 3 hachages par révision, et donc 300 hachages par référentiel.
Cela donne du pow (2, 47) pour 100 dépôts de 8 milliards de personnes, ce qui est encore loin du pow (2, 80).
Cependant, cela n'inclut pas l'effet de multiplication supposé mentionné ci-dessus, car je ne sais pas comment l'inclure dans cette estimation. Peut-être que cela pourrait augmenter considérablement les risques de collision. Surtout si de très grands répertoires recalent de très nombreux dépôts, ce qui crée néanmoins des hachages différents pour tous les commits concernés.
Eh bien, je suppose que nous savons maintenant ce qui se passerait - vous devriez vous attendre à ce que votre référentiel soit corrompu ( source ).