web-dev-qa-db-fra.com

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:

Stack Overflow question Pourquoi Git utilise-t-il SHA-1 comme numéros de version? demande pourquoi Git utilise SHA-1 plutôt que des nombres séquentiels pour les commits.

githash-function
135
Praxeolitic

TLDR;

Vous pouvez vérifier cela depuis 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 sur le plan cryptographique. Personne n'a été capable de 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 croient que depuis que git utilise SHA-1 et que SHA-1 est utilisé pour des choses sécurisées de manière cryptographique, 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 hasch que vous pouvez obtenir.

Avoir un bon hash est bon pour pouvoir faire confiance à vos données , il a aussi d'autres bonnes caractéristiques, ça veut dire quand on hache des objets, nous savons que le hash 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 la mise en œuvre, nous pouvons être certains que le hachage est tellement bon que nous pouvons utiliser des algorithmes de hachage et que nous savons qu'il n'y a pas de mauvais cas.

Il existe donc certaines raisons d’apprécier le côté cryptographique également, 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 être sûr que cinq ans plus tard, après la conversion de votre disque dur en DVD, quelle que soit la nouvelle technologie utilisée, vous l'avez copiée cinq ans plus tard, vous pouvez vérifier que les données que vous récupérez sont exactement les mêmes que celles que vous avez entrées. Et c'est quelque chose que vous devriez vraiment rechercher dans un système de gestion de code source .

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 une SHA plus moderne? ".

J'ai mentionné dans " comment git gérerait une collision SHA-1 sur un blob? " que pouvez créez un commit avec un SHA1 préfixe (encore une entreprise extrêmement coûteuse).
Mais le point reste inchangé car Eric Sink est mentionné dans " Git: Cryptographic Hash " ( livre (Version Control by Example (2011) book) =:

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

Il est plus difficile à trouver bon hachage non cryptographique avec un faible taux de collision, sauf si vous envisagez une recherche du type " Recherche de hachages à la pointe de la technologie avec programmation génétique ".

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

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

(Linus Torvalds)

Il n'y a pas vraiment quelque chose restant du code mozilla, mais bon, j'ai commencé à partir de ça. Rétrospectivement, j’aurais probablement dû partir du code PPC asm qui bloquait déjà de manière irréversible - mais c’est un peu "20/20 recul".

De plus, le code mozilla étant une pile de crud horrible, c’est pourquoi j’étais si convaincu de pouvoir améliorer les choses. C’est donc une sorte de source, même s’il s’agit davantage de motivation que de tout code restant;)

Et vous devez faire attention à comment mesurer le gain d'optimisation réel

(Linus Torvalds)

Je peux pratiquement vous garantir que cela améliore les choses uniquement parce que cela permet à gcc de générer du code merde, qui masque alors certains 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), ce qui permet d’avoir un emplacement pour une nouvelle valeur de hachage même s’il ne lit ni n’utilise cet espace - il utilise simplement la valeur de hachage SHA-1 qui se trouve dans l'autre emplacement.

Ainsi, une fois que nous aurons finalement déployé une version plus récente de git, appelons-la version 3, qui produit des hachages SHA-3 en plus des hachages SHA-1, les utilisateurs de git version 2 seront en mesure de continuer à inter-opérer.
(Bien que, selon cette discussion, ils puissent être vulnérables et les personnes qui dépendent de leurs correctifs SHA-1 uniquement peuvent être vulnérables.)

En bref, le passage à any hash n'est pas facile.

Mise à jour de février 2017: oui, il est théoriquement possible de calculer une collision SHA1: 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 de toutes les validations.
Il est essentiellement possible de créer deux référentiels GIT avec le même hachage de commit tête et un contenu différent, par exemple un code source bénin et un autre avec une porte dérobée.
Un attaquant pourrait potentiellement servir sélectivement l'un ou l'autre des référentiels aux utilisateurs ciblés. Cela nécessitera que les attaquants calculent leur propre collision.

Mais:

Cette attaque a nécessité plus de 9,223,372,036,854,775,708 calculs SHA1. Cela a pris la puissance de traitement équivalente à 6 500 ans de calculs à processeur unique et à 110 ans de calculs à processeur unique.

Donc, ne paniquons pas pour l'instant.
Plus d’informations sur " Comment Git gérerait-il une collision SHA-1 sur un blob? ".

193
VonC