Générateur de hash SHA-1

Des chercheurs du CWI et de Google ont publié SHAttered : deux fichiers PDF différents ayant le même SHA-1. Cela coûtait alors environ 6 500 années de calcul processeur, ce qui semble prohibitif et ne l’était pas — cela se loue. Trois ans plus tard, une collision à préfixe choisi était démontrée pour à peu près le prix d’une voiture d’occasion, et le coût n’a fait que baisser depuis.

Une collision à préfixe choisi est la variante dangereuse : elle permet de partir de deux documents porteurs de sens plutôt que de deux blocs de bruit. C’est le moment où une fonction de hachage cesse d’être utilisable pour des signatures, et c’est pourquoi les autorités de certification ont cessé d’émettre des certificats SHA-1 et les navigateurs de les accepter.

Chaque objet Git est nommé par son SHA-1, ce qui paraît alarmant et ne l’est pour l’essentiel pas. Git préfixe chaque objet par son type et sa longueur avant de le hacher, et depuis 2017 il embarque une routine de détection de collision qui rejette l’attaque connue — produire un objet en collision est donc bien plus difficile que produire un fichier en collision.

La migration vers SHA-256 est néanmoins réelle et lente : le format la prend en charge, et la transition est retenue par tous les outils, hébergeurs et scripts qui supposent quarante caractères. Si vous calculez un identifiant d’objet Git à la main, SHA-1 est encore la réponse, et il le restera quelques années.

Les mêmes choses que MD5, avec plus de marge : détecter une corruption accidentelle, dédupliquer du contenu, produire un identifiant stable là où personne ne gagne à une collision. Une collision doit être construite, et rien n’en construit une par accident.

La règle pratique est la même que partout ailleurs sur ce site. S’il existe quelqu’un qui gagne à ce que deux entrées différentes se correspondent, SHA-1 est fini. S’il n’existe personne, c’est une somme de contrôle parfaitement utilisable qui se trouve faire quarante caractères de long.

Les identifiants d’objets Git. HMAC-SHA1 dans d’anciens schémas de signature d’API — AWS Signature Version 2, OAuth 1.0, et une longue traîne d’intégrations internes qui ont copié l’un des deux. La sortie de `git describe`, les systèmes d’intégration continue indexés sur des identifiants de commit, et toute colonne de base dimensionnée à quarante caractères il y a dix ans.

HMAC-SHA1 mérite d’être mis à part : HMAC est une construction qui ne dépend pas de la résistance aux collisions du hash, donc HMAC-SHA1 n’est pas cassé de la façon dont les signatures SHA-1 le sont. Ce n’est toujours pas ce qu’un nouveau système devrait employer, mais ce n’est pas l’urgence que serait un certificat SHA-1.

SHA-1 fait quarante caractères hexadécimaux. MD5 en fait trente-deux, SHA-256 soixante-quatre, SHA-512 cent vingt-huit. Compter est le moyen le plus rapide d’identifier une empreinte qu’on vous a remise sans documentation, et cela vaut la peine avant de supposer quel algorithme un système emploie.

C’est aussi ainsi qu’une intégration périmée se signale. Un champ documenté comme SHA-256 qui contient quarante caractères contient du SHA-1, et ce n’est pas une bizarrerie de format : cela veut dire que quelque chose dans la chaîne n’a jamais été mis à jour quand la documentation l’a été.

Git affiche par défaut sept caractères d’un identifiant, ce qui suffit tant que le dépôt est petit. Le nombre de préfixes distincts nécessaires croît avec la racine carrée du nombre d’objets, si bien qu’un dépôt volumineux finit par produire deux objets partageant les sept mêmes premiers caractères.

Git s’en aperçoit et rallonge alors l’abréviation, ce qui explique pourquoi un dépôt ancien affiche des identifiants de neuf ou dix caractères là où un dépôt neuf en montre sept. Un identifiant court n’est donc jamais une valeur stable à stocker : c’est un affichage, et il change de longueur avec l’historique.

Une signature SHA-1 produite en 2012 n’est pas devenue fausse en 2017 : ce qui a changé, c’est ce qu’elle prouve. Elle atteste toujours qu’un document a été signé, et elle n’atteste plus qu’il n’a pas été remplacé par un autre document fabriqué pour avoir la même empreinte.

C’est pourquoi les archives légales et les systèmes d’horodatage ont dû re-signer leurs fonds plutôt que se contenter de changer d’algorithme pour l’avenir. Si vous héritez d’un système qui vérifie des signatures SHA-1 anciennes, la question n’est pas de savoir si l’algorithme est cassé — il l’est — mais si quelqu’un avait un intérêt à falsifier ce fonds précis.

SHA-1 est parfois écrit « SHA1 » ou simplement « SHA » dans une documentation ancienne, et ce dernier est le plus trompeur : le SHA d’origine, aujourd’hui appelé SHA-0, a été retiré en 1995 et remplacé par SHA-1 pour un défaut jamais publié en détail.

La conséquence est qu’un champ de configuration qui accepte « SHA » ne dit pas lequel. Quand un système ancien vous demande de choisir, la longueur de la sortie tranche : quarante caractères veut dire SHA-1, quoi que l’étiquette prétende.

Elle ne hache pas de fichier. SHA-1 sert le plus souvent à nommer un contenu, et un contenu est en général un fichier ; cette page prend du texte, parce que le champ de saisie est ce qui convient à une valeur qu’on recopie. Pour un fichier, l’outil de somme de contrôle du site prend le fichier directement.

Elle ne calcule pas non plus un identifiant d’objet Git, qui est le SHA-1 d’un en-tête suivi du contenu et non du contenu seul. Coller un fichier ici et s’étonner que l’empreinte ne corresponde pas à ce que `git hash-object` renvoie est une déception fréquente, et l’écart tient entièrement à ce préfixe.