Auteur Sujet: La résistance de SHA-1 aux collisions est plus menacée que jamais (Lu 9337 fois)

jack · « **Réponse #12 le:** 24 février 2017 à 22:42:00 »

Il convient de séparer les algorithmes de hashage en deux familles : d'une part, ceux à destination cryptographique (dont la découverte de collision est difficile, au prix de performances faibles), et ceux pour la comparaison de données (le fait de pouvoir trouver des collisions n'a aucune importance, ces algorithmes sont beaucoup plus rapide que les précédants)

Pour la première famille, sha1 n'est plus trop fiable (enfin, il faut relativiser ..)
Pour la deuxième, ça fait longtemps (voir "depuis toujours" ?) que sha1 ne fait pas le poids, versus des algorithmes bien plus intéressant, comme murmur3

corrector · « **Réponse #13 le:** 24 février 2017 à 22:57:06 »

Par exemple, on ne va pas utiliser un truc aussi lourd et lent que SHA1 (ou même MD5) pour faire par exemple de la détection d'erreur (brouillage, interférences...) sur un canal de transmission : il ne s'agit pas ici de contrer une attaque.

xav-stargate · « **Réponse #14 le:** 24 février 2017 à 23:08:07 »

Citation de: jack le 24 février 2017 à 22:42:00

Il convient de séparer les algorithmes de hashage en deux familles : d'une part, ceux à destination cryptographique

Tu utilises des algo de hash pour de la crypto

?

jack · « **Réponse #15 le:** 24 février 2017 à 23:38:50 »

Citation de: xav-stargate le 24 février 2017 à 23:08:07

Tu utilises des algo de hash pour de la crypto ?

Certes, et toi aussi : le certificat de lafibre.info utilise sha1 et sha256, par exemple (j'imagine que le premier est conservé pour retrocompabilité)

kgersen · « **Réponse #16 le:** 25 février 2017 à 01:00:50 »

Citation de: jack le 24 février 2017 à 23:38:50

Certes, et toi aussi : le certificat de lafibre.info utilise sha1 et sha256, par exemple (j'imagine que le premier est conservé pour retrocompabilité)

C'est le certificat racine qui utilise sha1 mais le certificat racine n'est pas vérifié, il est "implicitement" de confiance:

et le verification se fait comme ca:

corrector · « **Réponse #17 le:** 25 février 2017 à 01:19:26 »

Citation de: xav-stargate le 24 février 2017 à 23:08:07

Tu utilises des algo de hash pour de la crypto ?

Le hachage cryptographique est un composant fondamental dans de nombreux protocoles de sécurité, notamment :

les systèmes de signature basés sur la cryptographie asymétrique, notamment
- les certificats X.509 :
- notamment ceux comprenant un nom de domaine et servant de certificat TLS, notamment celui de lafibre; certificat TLS du client utilisé pour s'authentifier (à la place d'un mot de passe dans un formulaire)
- ouverture de session IPsec : IKE (Internet Key Exchange)
- authentification des hôtes ssh
- DNSSEC : les enregistrements DNS authentifiés : (méta)enregistrement DNS RRSIG authentifiant un enregistrement DNS ordinaire
- les courriels dont le contenu est signé par l'auteur : PGP (Pretty Good Privacy), GPG, S/MIME (Secure Multipurpose Internet Mail Extensions)
- les courriels dont le corps et certains entêtes sont signés par le robot SMTP d'envoi : DKIM
- les paquetages logiciels signés (ex. par GPG dans Debian)
- authentification des nœuds Tor
Intégrité de la configuration initiale, vérifiée localement, avec ou sans signature à clé publique :
- les programmes d'amorçage signés (vérifiés au moment du boot par le BIOS)
- kernel ou OS signés (signature vérifiée par le programme d'amorçage)
- les drivers Windows signés (vérifiés par le kernel)
- tout le "trusted programming" (TPM) repose à la base sur des "hash"
protocoles de transmission de paquets de données entre deux pairs partageant une ou plusieurs clefs secrètes, protégeant contre l'altération des données :
- protocoles de sécurité pour l'intégrité des données :
  - TCP au contenu authentifié : RFC 2385 (TCP MD5 Signature Option)
  - IPsec : trames IP protégées par Authentication Header (AH)
  - DNSSEC : mises à jour DNS sécurisée par signature TSIG
- protocoles de sécurité pour l'intégrité et la confidentialité des données basés sur des clefs secrètes connus des pairs :
  - TLS après l'ouverture de session, notamment HMAC-SHA1
  - flux bidirectionnels protégés par ssh (après l'ouverture de session)
  - IPsec : trames IP protégées par Encapsulating Security Payload (ESP)
  - messages chiffrés avec WPA(2)-TKIP, WPA(2)-CCMP
  
  Certains chiffres TLS modernes n'utilisent plus de hachage cryptographique, par exemple sur lafibre (chiffre AES_128_GCM).
les systèmes volontairement consommateurs de temps :
- les systèmes de preuve de travail ("hashcash"): systèmes où la production est très lente et la vérification très rapide; dont notamment :
  - le plus connu est utilisé dans le système de consensus cryptographique Bitcoin,
  - le plus tombé dans l'oubli est celui proposé par Bill Gates pour taxer l'envoi de courriels, reposent sur des hash
- Les système de vérification lente : les systèmes de renforcement des mots de passe/passphrases par obligation de fournir un effort pour les vérifier, notamment
  - PBKDF2 notamment utilisé dans WPA Personal et WPA2 Personal (WPA avec passphrase entrée sur tous les pairs)
  - bcrypt et son successeur scrypt
  ... utilisés notamment pour protéger les mots de passe des systèmes de type unixoïde dans /etc/shadow
protocoles d'authentification par mot de passe (connu des pairs) :
- protocoles d'authentification du client (pas du serveur), sans transmission en clair dans le canal de communication, utilisant un nonce :
  - HTTP digest authentication
  - authentification par mot de passe non transmis en clair sur POP, IMAP : CRAM-MD5
  
  (Ces méthodes ne créent pas de secret partagé et ne permettent pas d'initier une session sécurisée cryptographiquement liée.)
- protocole sécurisé de mot de passe, avec authentification mutuelle, assurant la protection contre toute interception/modification, permettant d'établir une sessions sécurisée (en créant un secret partagé) : SRP
authentification mutuelle style Kerberos à base de secret partagé
- les systèmes d'identification des fichiers par contenus, de dé-duplication
- système de gestion des versions : git
- système de stockage distribué et "peer to peer" notamment eDonkey, BitTorrent
les systèmes de preuve d'antériorité/horodatage, chaînage des publications, notamment :
- grand livre de compte de Bitcoin
- Certificate Transparency Logs
les protocoles de génération de nombre aléatoire sécurisé sans confiance mutuelle : dé virtuel lancé par des joueurs qui ne font pas confiance

Voilà ce qui me vient à l'esprit comme usage critique des hash cryptographiques, un peu en vrac (les catégories se chevauchent et se mélangent un peu).

corrector · « **Réponse #18 le:** 25 février 2017 à 10:18:34 »

Citation de: jack le 24 février 2017 à 22:42:00

Il convient de séparer les algorithmes de hashage en deux familles : d'une part, ceux à destination cryptographique (dont la découverte de collision est difficile, au prix de performances faibles), et ceux pour la comparaison de données (le fait de pouvoir trouver des collisions n'a aucune importance, ces algorithmes sont beaucoup plus rapide que les précédants)

Pour la première famille, sha1 n'est plus trop fiable (enfin, il faut relativiser ..)

Si, pour un notaire c'est foutu : tu dois vérifier des informations présentes dans un acte A et ensuite le certifier, en signant SHA1(A), tu l'as dans le baba!

Pour la protection d'un mot de passe par SHA1^n pour une grande valeur de n comme pour le hashcash, aucune importance.

Pour beaucoup d'autres usages, il faut une analyse plus poussée... SHA1 = terrain glissant!

corrector · « **Réponse #19 le:** 25 février 2017 à 11:16:19 »

Analyse préliminaire de Linus concernant l'impact sur git :

List: git
Subject: Re: SHA1 collisions found
From: Linus Torvalds <torvalds () linux-foundation ! org>
Date: 2017-02-23 17:19:06
Message-ID: CA+55aFxJGDpJXqpcoPnwvzcn_fB-zaggj=w7P2At-TOt4buOqw () mail ! gmail ! com
[Download message RAW]

On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess <id@joeyh.name> wrote:
>
> IIRC someone has been working on parameterizing git's SHA1 assumptions
> so a repository could eventually use a more secure hash. How far has
> that gotten? There are still many "40" constants in git.git HEAD.

I don't think you'd necessarily want to change the size of the hash.
You can use a different hash and just use the same 160 bits from it.

> Since we now have collisions in valid PDF files, collisions in valid git
> commit and tree objects are probably able to be constructed.

I haven't seen the attack yet, but git doesn't actually just hash the
data, it does prepend a type/length field to it. That usually tends to
make collision attacks much harder, because you either have to make
the resulting size the same too, or you have to be able to also edit
the size field in the header.

pdf's don't have that issue, they have a fixed header and you can
fairly arbitrarily add silent data to the middle that just doesn't get
shown.

So pdf's make for a much better attack vector, exactly because they
are a fairly opaque data format. Git has opaque data in some places
(we hide things in commit objects intentionally, for example, but by
definition that opaque data is fairly secondary.

Put another way: I doubt the sky is falling for git as a source
control management tool. Do we want to migrate to another hash? Yes.
Is it "game over" for SHA1 like people want to say? Probably not.

I haven't seen the attack details, but I bet

(a) the fact that we have a separate size encoding makes it much
harder to do on git objects in the first place

(b) we can probably easily add some extra sanity checks to the opaque
data we do have, to make it much harder to do the hiding of random
data that these attacks pretty much always depend on.

Linus

http://marc.info/?l=git&m=148787047422954

jack · « **Réponse #20 le:** 25 février 2017 à 11:36:37 »

Citation de: corrector le 25 février 2017 à 10:18:34

Si, pour un notaire c'est foutu : tu dois vérifier des informations présentes dans un acte A et ensuite le certifier, en signant SHA1(A), tu l'as dans le baba!

Pour la protection d'un mot de passe par SHA1^n pour une grande valeur de n comme pour le hashcash, aucune importance.

Pour beaucoup d'autres usages, il faut une analyse plus poussée... SHA1 = terrain glissant!

Les gens sérieux utilisent les hash pour trouver des potentiels match

Une vérification bit à bit s'impose par la suite

corrector · « **Réponse #21 le:** 25 février 2017 à 11:50:48 »

Citation de: jack le 25 février 2017 à 11:36:37

Les gens sérieux utilisent les hash pour trouver des potentiels match
Une vérification bit à bit s'impose par la suite

Hein? Quoi? Comment?

Tu parles de quoi, au juste?

Hugues · « **Réponse #22 le:** 25 février 2017 à 11:57:00 »

Comparaison de fichiers

corrector · « **Réponse #23 le:** 25 février 2017 à 12:08:58 »

Quels fichiers? Dans quel contexte?