Pourquoi Git n'utilise-t-il pas SHA plus moderne?

Pourquoi n'utilise-t-il pas une version plus moderne de SHA?

Déc. 2017: il sera. Et Git 2.16 (Q1 2018) est la première version pour illustrer et mettre en œuvre cette intention.

Note: voir Git 2.19 ci-dessous: ce sera SHA-256.

Git 2.16 proposera une infrastructure pour définir quelle fonction de hachage est utilisée dans Git, et commencera un effort pour sonder cela dans divers codepaths.

Voir commettre c250e02 (28 Novembre 2017) par Ramsay Jones (`) .
Voir commettre eb0ccfd, s'engager 78a6766, s'engager f50e766, s'engager abade65 (12 Novembre 2017) par brian m. carlson (bk2204).
^{(Fusionné par Junio C Hamano -- gitster -- dans commettre 721cc43, 13 Décembre 2017)}

Ajouter une structure représentant l'algorithme de hachage

Puisque dans le futur nous voulons soutenir un algorithme de hachage supplémentaire, ajoutez a structure qui représente un algorithme de hachage et toutes les données qui doivent l'accompagner.
Ajoutez une constante pour permettre une énumération facile des algorithmes de hachage .
Implémenter la fonction typedefs pour créer une API abstraite qui peut être utilisée par n'importe quel algorithme de hachage, et des wrappers pour les fonctions SHA1 existantes qui sont conformes à cette API.

Expose une valeur pour la taille hexadécimale ainsi que la taille binaire.
Alors que l'un sera toujours deux fois l'autre, le deux valeurs sont toutes deux utilisées extrêmement généralement tout au long de la base de code et de fournir les deux conduit à une meilleure lisibilité.

N'incluez pas d'entrée dans la structure de l'algorithme de hachage pour l'ID d'objet null.
Comme cette valeur est tous les zéros, tout ID d'objet tout-zéro de taille appropriée peut être utilisé, et il n'est pas nécessaire d'en stocker un par hachage.

Le plan de transition actuel de la fonction de hachage prévoit un moment où nous accepterons l'entrée de l'utilisateur qui pourrait être dans SHA-1 ou dans le format NewHash.
Puisque nous ne pouvons pas savoir qui l'utilisateur a fourni, ajouter un constante représentant l'algorithme inconnu afin de nous permettre d'indiquer que nous devons chercher la bonne valeur.

Intégrer la prise en charge de l'algorithme de hachage avec la configuration de repo

Dans les futures versions de Git, nous prévoyons de prendre en charge un hachage supplémentaire algorithme.
Intégrer l'énumération des algorithmes de hachage avec la configuration du référentiel, et stockez un pointeur vers les données énumérées dans struct repository.
Bien sûr, nous ne prenons actuellement en charge que SHA-1, donc codez en dur cette valeur dans read_repository_format.
À l'avenir, nous allons énumérer cette valeur à partir de la configuration.

Ajouter une constante, the_hash_algo, qui points à l' hash_algo pointeur de structure dans le référentiel global.
Notez qu'il s'agit du hachage utilisé pour sérialiser les données sur le disque, pas du hachage utilisé pour l'affichage des éléments à l'utilisateur.
Le plan de transition prévoit que ceux-ci peuvent être différents.
Nous pouvons ajouter un élément supplémentaire à l'avenir (par exemple, ui_hash_algo) pour prévoir ce cas.

Mise à jour août 2018, pour Git 2.19 (Q3 2018), Git semble choisir SHA-256 Comme NewHash.

Voir commettre 0ed8d8d (04 Août 2018) par Jonathan Nieder (artagnon).
Voir commit 13f5e09 (25 juil 2018) par Ævar Arnfjörð Bjarmason (avar).
^{(Fusionné par Junio C Hamano -- gitster -- dans commettre 34f2297, 20 Août 2018)}

De réf hash-function-transition: choisissez SHA-256 comme NewHash

Du point de vue de la sécurité, il semble que SHA-256, BLAKE2, SHA3-256, K12, et ainsi de suite ont tous des propriétés de sécurité similaires.
Toutes sont de bonnes options d'un point de vue de la sécurité.

SHA-256 a un certain nombre d'avantages:

• Il existe depuis un moment, est largement utilisé et est supporté par à peu près toutes les bibliothèques cryptographiques (OpenSSL, mbedTLS, CryptoNG, SecureTransport, etc.).

• Lorsque vous comparez avec SHA1DC, la plupart des implémentations SHA-256 vectorisées sont en effet plus rapides, même sans accélération.

• Si nous faisons des signatures avec OpenPGP (ou même, je suppose, CMS), nous allons utiliser SHA-2, donc cela n'a pas de sens d'avoir notre sécurité dépend de deux algorithmes distincts lorsque l'un d'eux seul pourrait briser la sécurité alors que nous pourrions simplement dépendre d'un.

Donc SHA-256 c'est .
Mettez à jour le document de conception hash-function-transition pour le dire.

Après ce patch, il n'y a plus d'instances de la chaîne "NewHash", sauf pour une utilisation non liée de 2008 comme un nom de variable dans t/t9700/test.pl.

Ceci est une discussion sur l'urgence de migrer loin de SHA1 pour Mercurial, mais cela s'applique aussi à Git: https://www.mercurial-scm.org/wiki/mpm/SHA1

En bref: si vous n'êtes pas extrêmement dilligent aujourd'hui, vous avez des vulnérabilités bien pires que sha1. Mais malgré cela, Mercurial a commencé il y a plus de 10 ans pour se préparer à migrer loin de sha1.

Des travaux sont en cours depuis des années pour moderniser les structures de données et les protocoles de Mercurial pour les SHA1 successeur. L'espace de stockage a été alloué pour des hachages plus importants dans notre structure revlog il y a plus de 10 ans dans Mercurial 0.9 avec L'introduction de RevlogNG. Le format bundle2 introduit plus récemment prend en charge l'échange de différents types de hachage sur le réseau. Les seules pièces restantes sont le choix d'une fonction de remplacement et le choix d'une stratégie de rétrocompatibilité.

Si git ne migre pas de sha1 avant Mercurial, vous pouvez toujours ajouter un autre niveau de sécurité en gardant un miroir Mercurial local avec hg-git .

Il y a maintenant un plan de transition vers un hachage plus fort, il semble donc qu'à l'avenir il utilisera un hachage plus moderne que SHA-1. Du plan de transition actuel :

Certains hachages considérés sont SHA-256, SHA-512/256, SHA-256x16, K12 et BLAKE2bp-256