Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Collision SHA-1 : « le Ciel ne nous tombe pas sur la tête », Linus Torvalds veut rassurer les utilisateurs GIT
Quant aux implications de l'annonce

Le , par Stéphane le calme

30PARTAGES

12  0 
Il y a quelques jours, une équipe composée de chercheurs issus du Centrum Wiskunde et Informatica (CWI, Pays-Bas) et de Google a annoncé avoir mis au point une méthode pour briser l'algorithme SHA-1 qui a longtemps été utilisé pour vérifier l'authenticité des documents numériques. Dans le cadre de la rédaction détaillée de leur réalisation, les chercheurs ont également publié deux fichiers PDF comme preuve de la collision réalisée, les deux fichiers ayant des hachages SHA-1 identiques, mais affichant des contenus différents.

Ils ont mis à jour le site web dédié à l’évènement autour de la collision de hash pour indiquer des conséquences sur certains systèmes à l’instar de GIT. La raison ? « 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 commit de tête et différents contenus, par exemple un code source bénin et un disposant d’une porte dérobée. Un attaquant pourrait potentiellement servir sélectivement l’un ou l’autre des dépôts aux utilisateurs ciblés. Cela exigera des attaquants de calculer leur propre collision ».

Pour rappel, Linus Torvalds et d'autres développeurs de noyau Linux ont créé GIT en 2005 comme système de contrôle de version distribué de Linux. Il est également utilisé par de nombreuses grandes entreprises, y compris Facebook, Google et Twitter, pour gérer leurs bases de code. GIT est également utilisé dans GitHub, l’un des sites de gestion de code source les plus populaires au monde.

Raison pour laquelle Linus Torvalds s’est penché sur le problème et a livré les résultats de son analyse.

« Tout d'abord, le ciel ne nous tombe pas sur la tête. Il y a une grande différence entre utiliser d'un hachage cryptographique pour des choses comme une signature de sécurité et s’en servir pour générer un "identificateur de contenu" d’un système de contenu-adressable comme git », a assuré Linus.

La différence résidant donc dans la raison de l’utilisation. « Un hachage qui est utilisé pour la sécurité est essentiellement une déclaration de confiance : et si vous pouvez tromper quelqu'un, vous pouvez l’emmener à vous faire confiance même quand il ne devrait pas vraiment  ». Raison pour laquelle « lorsqu'un tel hachage est rompu, la raison même du hash disparaît fondamentalement ».

En revanche, dans un projet comme git, le hachage n'est pas utilisé pour la « confiance » : « notre confiance est dans les gens, et puis nous finissons par avoir beaucoup de mesures technologiques en place pour sécuriser les données réelles ». La raison de l'utilisation d'un hachage cryptographique dans un projet comme git est parce qu'il garantit à peu près qu'il n'y a pas d'affrontements accidentels, et est également excellent dans la détection d’erreurs ; même s’il n’est pas en mesure de corriger les erreurs, il est très bon lorsqu’il faut détecter les données corrompues.

« Deuxièmement, la nature particulière de cette attaque SHA-1 signifie qu'elle est réellement assez facile à atténuer, et il y a déjà eu deux ensembles de correctifs affichés pour cette atténuation », a-t-il continué. Linus note deux choses :
  • l'attaquant ne peut pas simplement générer une collision aléatoire, mais doit être capable de contrôler et de générer à la fois le « bon » et le « mauvais » objet ;
  • vous pouvez réellement détecter les signes de l'attaque dans les deux côtés de la collision.

Linus explique que la première remarque implique qu’il est vraiment difficile de cacher l'attaque dans des données qui sont transparentes (par données transparentes, il parle du fait que « vous voyez réellement et réagissez à toutes les données, au lieu d’avoir une espèce de “ bulle ” de données qui agit comme une boîte noire et ne vous permet de ne voir que les résultats finals).

« Dans les exemples PDF, le format PDF a agi comme "la boîte noire", et ce que vous voyez est l'impression qui a seulement une relation très indirecte au codage de pdf. Mais si vous utilisez git pour le contrôle de source comme dans le noyau, les choses dont vous vous souciez vraiment est le CODE SOURCE, qui est très transparent », a-t-il rappelé. « Alors, fondamentalement, si les données dont vous vous souciez principalement sont ce genre de code source transparent, l'attaque est assez limitée. Vous VERREZ l'attaque. Elle ne va pas silencieusement modifier vos données devant vous ».

En plus de ces arguments, Linus rappelle « qu’il y a effectivement une transition assez simple vers un autre hash qui ne va pas briser le monde - ou même de vieux dépôts git ». Il a expliqué que git finira par s'éloigner de SHA1 : « il y a un plan, il ne semble pas du tout mauvais, et vous n'aurez même pas à convertir votre dépôt ».

Source : billet Linus Torvalds

Et vous ?

Que pensez-vous des raisons qu'il a évoquées ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 28/02/2017 à 8:00
Citation Envoyé par Artemus24 Voir le message
[...]Ok, je comprends mieux ! Mais je ne voie toujours pas l'intérêt de cette multiplicité des hash.
Par analogie, auriez-vous intérêt à mettre plusieurs serrures douteuses sur votre porte, où bien une seule si elle est infalsifiable ?
Toutes les serrures quelles soient de bonne ou mauvaise qualité ne survivent à la perceuse et le foret métal, plus tu à de serrures plus c'est long à ouvrir
2  0 
Avatar de Beanux
Membre éclairé https://www.developpez.com
Le 27/02/2017 à 17:26
Citation Envoyé par Artemus24 Voir le message

Ne peut-on pas trouver une autre technique qui consisterait à verrouiller le fichier et que seul celui qui va l'utiliser pourrait le déverrouiller. Cela garanti aucune falsification, non ?
Il en existe plein d'autre, par exemple, le SHA2 est aussi une fonction de hachage qui elle est encore fiable. Et le SHA3 est aussi la pour proposer une alternative viable au SHA2.

Citation Envoyé par Artemus24 Voir le message

J'avais en tête le chiffrement d'un texte. Or "Dourouc05" me confirme que cela n'a aucun rapport, juste la création d'une emprunte afin de garantir qu'il n'y a, par son auteur, aucune falsification.
Donc les termes de chiffrer ou de crypter ne sont pas appropriés.
Citation Envoyé par Artemus24 Voir le message

Or là, je ne comprends plus très bien. Est-ce pour crypter un texte ou juste garantir que ce texte n'a pas été falsifié ?
Car Dourouc05 dit que c'est une emprunte et vous, un cryptage non réversible.
Le terme crypter est un terme qui est mal utilisé (normalement il n'existe pas) dans la langue française: https://chiffrer.info/
Le mot cryptage (pour moi), peut être employé à cette fin, parce que c'est une méthode à sens unique. Néanmoins je concède que cela prête a confusion.

Citation Envoyé par Artemus24 Voir le message

Je ne suis pas du tout convaincu de ce que vous dites. Dans l'exemple donné du hash sha-1, il y a une emprunte de 160 bits.
Vous pouvez utiliser autant d'algorithme que vous désirez, pour complexifié votre emprunte, au final, elle aura toujours 160 bits.
Je vous invite à lire la page wikipédia des fonctions de hachage. Elle vous expliquera très bien le des fonctions de hachage (la partie considérations mathématique peut être passé).
Mais l’intérêt n’est pas qu'il y ai une unicité absolue des empreintes/hash, c’est la non réversibilité de cette opération qui est importante.
Il est important qu'il y ai un grand nombre d'empreinte aussi, et sur 160 bit, les chercheurs en sécurité ont estimé cela suffisant.

En revanche je ne comprends pas ce que vous mentionnez en parlant de "bug en cascade".
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/02/2017 à 17:37
Visiblement Subversion est moins résilient que Git aux collisions SHA1...
https://arstechnica.com/security/201...rs-may-follow/
1  0 
Avatar de Iradrille
Expert confirmé https://www.developpez.com
Le 27/02/2017 à 19:41
Citation Envoyé par Artemus24 Voir le message
Ne peut-on pas trouver une autre technique qui consisterait à verrouiller le fichier et que seul celui qui va l'utiliser pourrait le déverrouiller. Cela garanti aucune falsification, non ?
Il y a d'autres méthodes; par exemple chiffrer le fichier et donner sa clef publique; l'utilisateur peut le télécharger et le déchiffrer. Personne d'autre ne pourra chiffrer un fichier avec la même clef privée (tant que l'algo de chiffrement / génération de clefs résiste aux attaques bien sur).

Mais c'est bien moins pratique qu'un hash.

Citation Envoyé par Artemus24 Voir le message
Or là, je ne comprends plus très bien. Est-ce pour crypter un texte ou juste garantir que ce texte n'a pas été falsifié ?
Car Dourouc05 dit que c'est une emprunte et vous, un cryptage non réversible.
Les deux.

Tu stoques des mots de passe en base de données : tu vas stocker un hash des pass et non les pass en clair.
Quand un utilisateur se connecte, tu hash son pass et compare les hashs.
Dans ce cas on peut voir ça comme une forme de cryptage.

Tu mets un fichier à télécharger sur ton site.
L'utilisateur veut s'assurer que le fichier est correct (téléchargé correctement / pas modifié par une tierce personne) : il hash le fichier et compare le hash à un hash de référence que tu as calculé. Si c'est identique le fichier est bon.
(Bien sur si quelqu'un accède à ton serveur et modifie le fichier, il y a de grandes chances qu'il modifie le hash de référence; mais c'est un autre problème).

Çà sert aussi à comparer rapidement des fichiers / objets (cas d'SVN ou de hashtable).
1  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 27/02/2017 à 20:54
Citation Envoyé par Artemus24 Voir le message
[...]Je ne suis pas du tout convaincu de ce que vous dites. Dans l'exemple donné du hash sha-1, il y a une emprunte de 160 bits.
Vous pouvez utiliser autant d'algorithme que vous désirez, pour complexifié votre emprunte, au final, elle aura toujours 160 bits.
Je ne parlait pas de faire le Hash du Hash pour vérifier mais d'utiliser les 2 hash ou plus comme références des fichier et on s'assure de l'authenticité si le fichier correspond aux X hash de référence
1  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 28/02/2017 à 8:26
Faut quand même pas non plus oublier qu'on parle de 6500 années CPU pour arriver à une collision , dans des conditions probablement favorables.
Alors effectivement il faudra sans doute envisager de basculer GIT vers autre chose mais j'y vois pas une faille de sécurité.
1  0 
Avatar de Beanux
Membre éclairé https://www.developpez.com
Le 28/02/2017 à 10:22
Citation Envoyé par tomlev Voir le message
Le "cryptage" n'existe pas, ça s'appelle le chiffrement. Et le chiffrement, c'est réversible, contrairement au hachage. Donc non, ce n'est pas du chiffrement.
Justement linguistiquement parlant le cryptage existe, il ne fait pas référence au chiffrement. Sa signification est simplement d'encoder quelque chose sans en connaitre la clé inverse. Ce qui correspond plutôt correctement au hachage.

https://chiffrer.info/
1  0 
Avatar de gurkuru
Nouveau membre du Club https://www.developpez.com
Le 28/01/2020 à 0:29
Ben y'a juste un problème oublié avec les fonctions à sens unique, faut encore valider le produit de l'opération. Ce qui impose une validation par comparaison (seul moyen de vérifier que le résultat obtenu est valide).
Et avec la croissance constante de la longueur des clés de vérification, les bases de données qui servent au stockage des validations augmentent en taille de manière considérable, et fragilisent celle-ci.
La seule méthode connue encore viable aujourd'hui de cryptage est celle du masque jetable, avec ces contrainte que sont l'unicité d'usage, mais aussi la communication des masques.
RSA devait compenser la seconde, avec un cryptage à sens unique où seule les clés de cryptage sont échangées, les compléments des clés servant au décryptage restant connues uniquement de expéditeurs.
SHA lui sert a vérifier la validité des données communiquées, mais n'est pas à sens unique, c'est juste un calcul avec contraintes, compliqué et stable, mais (comme exemple), on peut faire des glaçons avec de l'eau de source, et aussi de l'eau de mer.
Donc on peut tromper le vérificateur car seul un contact direct avec l'expéditeur permet de s'assurer de ce qui est viable ou non. Ce qu'aucune signature numérique (et donc déportée et copiable) ne peut faire.
Le mieux qui reste disponible est encore de communiquer en clair, avec vérification de chaque étape, enregistrée dans le message, du départ à l'arrivée, avec controle ouvert des données envoyées (type blockchain). Mais pour les amoureux du secret, sur que ça coince (surtout dans la finance).
1  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 27/02/2017 à 22:22
Salut à tous.

Citation Envoyé par Beanux
Il en existe plein d'autre, par exemple, le SHA2 est aussi une fonction de hachage qui elle est encore fiable. Et le SHA3 est aussi la pour proposer une alternative viable au SHA2.
Je ne parlais pas du hashage, mais d'une autre approche. C'est le principe de l'emprunte que que je mets en doute.
Réduire un fichier selon un algorithme pour obtenir quelque chose faisant (dans le cas du sha-1) 160 bits, il y aura nécessairement des collisions.

Citation Envoyé par Beanux
c’est la non réversibilité de cette opération qui est importante.
Elle vous eet à quoi cette non réversibilité si la taille de l'emprunte est trop petite.
Et quand on aura des ordinateurs quantiques, à combien jugez-vous la taille de cette emprunte ?
En fait, le problème repose sur le temps nécessaire pour obtenir le résultat recherché.

Citation Envoyé par Beanux
En revanche je ne comprends pas ce que vous mentionnez en parlant de "bug en cascade".
Ceci :

Citation Envoyé par Stéphane Le Calme
« s'il vous plaît, faites attention, étant donné que les collisions des fichiers SHA-1 brisent actuellement les dépôts SVN. Les serveurs Subversion utilisent SHA-1 pour la déduplication et les référentiels sont corrompus lorsque deux fichiers collisionnels sont affectés au référentiel. Cela a été découvert dans le référentiel Subversion de WebKit et confirmé de manière indépendante par nous. Nous avons remarqué que dans certains cas, en raison de la corruption, d'autres commits sont bloqués ».
Surtout quand les chercheurs disent "d'autre commits sont bloqués".

Citation Envoyé par Iradrille
par exemple chiffrer le fichier et donner sa clef publique;
Je crois que cela se nomme le RSA, non ? Encore des modulos.

Citation Envoyé par Iradrille
Tu stoques des mots de passe en base de données : tu vas stocker un hash des pass et non les pass en clair.
Quand un utilisateur se connecte, tu hash son pass et compare les hashs.
Dans ce cas on peut voir ça comme une forme de cryptage.
Je connais le principe. Mais c'est du cryptage !
L'intérêt est limité à l'usage des mots de passe, pas à quelque chose qui peut être craqué si on dispose de la puissance d'un super ordinateur.

Citation Envoyé par TiranusKBX
Je ne parlais pas de faire le Hash du Hash pour vérifier mais d'utiliser les 2 hash ou plus comme références des fichier et on s'assure de l'authenticité si le fichier correspond aux X hash de référence
Ok, je comprends mieux ! Mais je ne voie toujours pas l'intérêt de cette multiplicité des hash.
Par analogie, auriez-vous intérêt à mettre plusieurs serrures douteuses sur votre porte, où bien une seule si elle est infalsifiable ?

@+
0  1 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/02/2017 à 23:51
Citation Envoyé par Artemus24 Voir le message
Réduire un fichier selon un algorithme pour obtenir quelque chose faisant (dans le cas du sha-1) 160 bits, il y aura nécessairement des collisions.
Oui, mais la probabilité que ça arrive par accident est infime, donc en pratique ce n'est pas vraiment un souci. Par contre, ça devient problématique si quelqu'un est capable de générer ces collisions volontairement...

Citation Envoyé par Artemus24 Voir le message
Je connais le principe. Mais c'est du cryptage !
Le "cryptage" n'existe pas, ça s'appelle le chiffrement. Et le chiffrement, c'est réversible, contrairement au hachage. Donc non, ce n'est pas du chiffrement.
0  1