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

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.

TLDR;

• de 2005 à 2018 / Git 2.18: SHA-1 (voir ci-dessous)
• 2019, passera à un moment donné à SHA-256

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:

• soit pour l'optimiser (août 2009) , mais il faut prendre un problème de licence:

(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.

• ou pour le changer complètement (janvier 2010)
  (par exemple en SHA-3, mais cela s'appliquerait à tout autre hachage):

(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? ".