Pourquoi Git utilise-t-il une fonction de hachage cryptographique?

139

Pourquoi Git utilise -t-il SHA-1 , une fonction de hachage cryptographique, au lieu d'une fonction de hachage non cryptographique plus rapide?

Question connexe:

Question Stack Overflow Pourquoi Git utilise SHA-1 comme numéros de version? demande pourquoi Git utilise SHA-1 par opposition aux nombres séquentiels pour les commits.

Praxéolitique
la source
Personnellement, je pense que même utiliser SHA-1 cassé sur SHA-2 était une optimisation prématurée.
CodesInChaos du
7
@CodesInChaos: et en plus, intégrer un algorithme particulier dans le code était une horrible violation des principes de DI. Devrait être dans un fichier de configuration XML quelque part ;-)
Steve Jessop
Mise à jour de décembre 2017 avec Git 2.16 (Q1 2018): un effort de prise en charge d'un SHA alternatif est en cours: voir " Pourquoi Git n'utilise-t-il pas un SHA plus moderne? ".
VonC
Il n'y a pas de bons hachages non cryptographiques de 160 bits ou plus. La plupart sont des fonctions 32 bits, 64 bits ou 128 bits hautement optimisées. 128 bits, c'est bien, mais j'ai le sentiment que 128 bits est un peu faible pour un gros projet comme git. Si un hachage 224/256 bits rapide et de haute qualité sortait, ce serait probablement l'idéal.
bryc

Réponses:

197

TLDR;


Vous pouvez le vérifier auprès de Linus Torvalds lui-même, lorsqu'il a présenté Git à Google en 2007 :
(c'est moi qui souligne)

Nous vérifions les sommes de contrôle considérées comme sécurisées par cryptographie. Personne n'a pu casser SHA-1, mais le fait est que SHA-1 en ce qui concerne git, n'est même pas une fonctionnalité de sécurité. C'est purement un contrôle de cohérence .
Les pièces de sécurité sont ailleurs. Beaucoup de gens supposent que puisque git utilise SHA-1 et que SHA-1 est utilisé pour des choses cryptographiquement sécurisées, ils pensent que c'est une fonctionnalité de sécurité énorme. Cela n'a rien à voir avec la sécurité, c'est juste le meilleur hachage que vous puissiez obtenir.

Avoir un bon hachage est bon pour pouvoir faire confiance à vos données , il se trouve qu'il a également d'autres bonnes fonctionnalités, cela signifie que lorsque nous hachons des objets, nous savons que le hachage est bien distribué et nous n'avons pas à nous soucier de certains problèmes de distribution .

En interne, cela signifie que du point de vue de l'implémentation, nous pouvons être sûrs que le hachage est si bon que nous pouvons utiliser des algorithmes de hachage et savoir qu'il n'y a pas de mauvais cas.

Il y a donc des raisons d'aimer aussi le côté cryptographique, mais il s'agit vraiment de la capacité de faire confiance à vos données.
Je vous garantis que si vous mettez vos données dans git, vous pouvez avoir confiance dans le fait que cinq ans plus tard, après avoir été converti de votre disque dur en DVD vers n'importe quelle nouvelle technologie et que vous l'avez copié, cinq ans plus tard, vous pouvez vérifier les données que vous get back est exactement les mêmes données que vous avez insérées. Et c'est quelque chose que vous devriez vraiment rechercher dans un système de gestion de code source .


Mise à jour de décembre 2017 avec Git 2.16 (Q1 2018): cet effort de prise en charge d'un SHA alternatif est en cours: voir " Pourquoi Git n'utilise-t-il pas un SHA plus moderne? ".


J'ai mentionné dans " Comment git gérerait une collision SHA-1 sur un objet blob? " Que vous pouviez créer un commit avec un préfixe SHA1 particulier (encore une entreprise extrêmement coûteuse).
Mais le point demeure, comme le mentionne Eric Sink dans le livre " Git: Cryptographic Hashes " ( Version Control by Example (2011) :

Il est assez important que le DVCS ne rencontre jamais deux éléments de données différents ayant le même condensé. Heureusement, de bonnes fonctions de hachage cryptographique sont conçues pour rendre de telles collisions extrêmement improbables.

Il est plus difficile de trouver un bon hachage non cryptographique avec un faible taux de collision, à moins que vous ne preniez en compte des recherches comme « Trouver des hachages non cryptographiques de pointe avec la programmation génétique ».

Vous pouvez également lire " Envisagez d'utiliser un algorithme de hachage non cryptographique pour accélérer le hachage ", qui mentionne par exemple " xxhash ", un algorithme de hachage non cryptographique extrêmement rapide, fonctionnant à des vitesses proches des limites de la RAM.


Les discussions sur la modification du hachage dans Git ne sont pas nouvelles:

(Linus Torvalds)

Il ne reste vraiment rien du code mozilla, mais bon, je suis parti de là. Rétrospectivement, j'aurais probablement dû partir du code asm PPC qui a déjà bloqué correctement - mais c'est une sorte de "rétrospective 20/20".

De plus, le code mozilla étant un tas de crudités horribles, c'était pourquoi j'étais si convaincu que je pouvais améliorer les choses. C'est donc une sorte de source pour cela, même s'il s'agit plus du côté de la motivation que de tout code restant;)

Et vous devez faire attention à la façon de mesurer le gain d'optimisation réel

(Linus Torvalds)

Je peux à peu près vous garantir que cela améliore les choses uniquement parce que cela permet à gcc de générer du code de merde, ce qui masque ensuite certains des problèmes P4.

(John Tapsell - johnflux)

Le coût d'ingénierie pour la mise à niveau de git de SHA-1 vers un nouvel algorithme est beaucoup plus élevé . Je ne sais pas comment cela peut être bien fait.

Tout d'abord, nous devons probablement déployer une version de git (appelons-la version 2 pour cette conversation) qui permet qu'il y ait un emplacement pour une nouvelle valeur de hachage même si elle ne lit pas ou n'utilise pas cet espace - il utilise juste la valeur de hachage SHA-1 qui se trouve dans l'autre emplacement.

De cette façon, une fois que nous aurons finalement déployé une version plus récente de git, appelons-la la version 3, qui produit des hachages SHA-3 en plus des hachages SHA-1, les personnes utilisant git version 2 pourront continuer à interopérer.
(Bien que, d'après cette discussion, ils puissent être vulnérables et les personnes qui comptent sur leurs correctifs SHA-1 uniquement peuvent être vulnérables.)

En bref, passer à n'importe quel hachage n'est pas facile.


Mise à jour février 2017: oui, il est en théorie possible de calculer un SHA1 en collision: shattered.io

Comment GIT est-il affecté?

GIT s'appuie fortement sur SHA-1 pour l'identification et la vérification de l'intégrité de tous les objets de fichier et commits.
Il est essentiellement possible de créer deux référentiels GIT avec le même hachage de commit principal et des contenus différents, disons un code source bénin et un code backdoor.
Un attaquant pourrait potentiellement servir sélectivement l'un des référentiels aux utilisateurs ciblés. Cela obligera les attaquants à calculer leur propre collision.

Mais:

Cette attaque a nécessité plus de 9 223 372 036 854 775 808 calculs SHA1. Cela a nécessité une puissance de traitement équivalente à 6500 ans de calculs sur un seul processeur et 110 ans de calculs sur un seul GPU.

Alors ne paniquons pas pour l'instant.
Pour en savoir plus, consultez " Comment Git gérerait une collision SHA-1 sur un objet blob? ".

VonC
la source
8
Il semble que la récente récolte de fonctions de hachage non cryptographiques de haute qualité, comme xxhash, soit sortie un peu trop tard - juste après git.
Praxeolitic
3
@Praxeolitic en effet. Il y a eu des discussions sur le remplacement de SHA1 par un autre hachage, mais cela nécessiterait simplement un peu de travail, pour quelque chose qui, pour l'instant, fonctionne bien.
VonC
"nous savons que le hachage est bien distribué et nous n'avons pas à nous soucier de certains problèmes de distribution" - pourquoi est-ce un problème pour scm?
rodé
@roded le taux de collision est suffisamment bas pour être bien adapté à un SCM où les données ne sont généralement pas aléatoires mais testent des fichiers.
VonC
1
En fait, il y a une raison de sécurité à utiliser un hachage cryptographique. Quand un auteur (disons Linus) veut couper une version (disons Linux), les gens veulent savoir que le code source qu'ils téléchargent correspond à ce que l'auteur avait l'intention d'inclure dans la version. À cette fin, le dernier hachage de validation de la version est balisé et la balise est signée. Si la chaîne de hachage de validation se terminant par la balise n'était pas cryptographiquement sécurisée, la source pourrait être maculée à autre chose que ce que l'auteur voulait.
Christopher King