La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: corrector le 24 décembre 2015 à 03:44:08
-
This website contains latest news and background information regarding the SHA-1 freestart collision work from Marc Stevens (CWI, the Netherlands), Pierre Karpman (Inria, France and NTU Singapore) and Thomas Peyrin (NTU Singapore).
(...)
We recommend that SHA-1 based signatures should be marked as unsafe much sooner than prescribed by current international policy. Even though freestart collisions do not directly lead to actual collisions for SHA-1, in our case, the experimental data we obtained in the process enable significantly more accurate projections on the real-world cost of actual collisions for SHA-1, compared to previous projections. Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months. By contrast, security expert Bruce Schneier previously projected (based on calculations from Jesse Walker) the SHA-1 collision cost to be ~173K$ by 2018. Note that he deems this to be within the resources of a criminal syndicate. Large corporations and governments may possess even greater resources and may not require Amazon EC2. Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 based SSL certificates by 2017 (and that SHA-1-based certificates should not be issued after 2015). In conclusion, our estimates imply SHA-1 collisions to be now (Fall 2015) within the resources of criminal syndicates, two years earlier than previously expected and one year before SHA-1 will be marked as unsafe in modern Internet browsers. This motivates our recommendations for industry standard SHA-1 to be retracted as soon as possible. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (discussion closes October 9 2015, vote closes October 16).
Marc Stevens is supported by the Netherlands Organization for Scientific Research Veni Grant 2014.
Pierre Karpman and Thomas Peyrin are supported by the Singapore National Research Foundation Fellowship 2012 (NRF-NRFF2012-06).
Pierre Karpman is also supported by the Direction Générale de l'Armement.
https://sites.google.com/site/itstheshappening/
Cryptology ePrint Archive: Report 2015/967
Freestart collision on full SHA-1
Marc Stevens and Pierre Karpman and Thomas Peyrin
Abstract: We present in this article a freestart collision example for SHA-1, i.e., a collision for its internal compression function. This is the first practical break of the full SHA-1, reaching all 80 out of 80 steps, while only 10 days of computation on a 64 GPU cluster were necessary to perform the attack. This work builds on a continuous series of cryptanalytic advancements on SHA-1 since the theoretical collision attack breakthrough in 2005. In particular, we extend the recent freestart collision work on reduced-round SHA-1 from CRYPTO 2015 that leverages the computational power of graphic cards and adapt it to allow the use of boomerang speed-up techniques. We also leverage the cryptanalytic techniques by Stevens from EUROCRYPT 2013 to obtain optimal attack conditions, which required further refinements for this work.
Freestart collisions, like the one presented here, do not directly imply a collision for SHA-1. However, this work is an important milestone towards an actual SHA-1 collision and it further shows how graphics cards can be used very efficiently for these kind of attacks. Based on the state-of-the-art collision attack on SHA-1 by Stevens from EUROCRYPT 2013, we are able to present new projections on the computational/financial cost required by a SHA-1 collision computation. These projections are significantly lower than previously anticipated by the industry, due to the use of the more cost efficient graphics cards compared to regular CPUs.
We therefore recommend the industry, in particular Internet browser vendors and Certification Authorities, to retract SHA-1 soon. We hope the industry has learned from the events surrounding the cryptanalytic breaks of MD5 and will retract SHA-1 before example signature forgeries appear in the near future. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (vote closes October 9 2015).
Category / Keywords: public-key cryptography / SHA-1, hash function, cryptanalysis, freestart collision, GPU implementation
Date: received 8 Oct 2015
https://eprint.iacr.org/2015/967
COMMENTAIRE
On savait que ça nous menaçait, qu'il fallait basculer vers des fonction de compression plus robustes... mais certains rétrogrades traînent des pieds.
-
Beaucoup en sont conscients. Le NIST a choisi quel remplaçant au fait ? Je m'étais arrêté quand il restait encore une poignée de candidat. (Si ils ont choisi d'ailleurs, c'est peut être encore en cours)
-
SHA-256 pour Windows
La seule modification de Firefox 43.0.1 est justement d'abandonner SHA-1 : => https://www.mozilla.org/en-US/firefox/43.0.1/releasenotes/
Microsoft arrête le support de SHA-1 au 1er janvier 2016.
Par contre ce n'est pas compatible avec Windows XP SP2 (ok avec Windows XP SP3).
Mozilla assurant toujours des mises à jour de Firefox pour Windows XP SP2, je ne sais pas comment ils vont contourner le pb pour que l'installation fonctionne sous Win XP SP2.
-
SHA-256 pour Windows
La seule modification de Firefox 43.0.1 est justement d'abandonner SHA-1 : => https://www.mozilla.org/en-US/firefox/43.0.1/releasenotes/
Microsoft arrête le support de SHA-1 au 1er janvier 2016.
Par contre ce n'est pas compatible avec Windows XP SP2 (ok avec Windows XP SP3).
Mozilla assurant toujours des mises à jour de Firefox pour Windows XP SP2, je ne sais pas comment ils vont contourner le pb pour que l'installation fonctionne sous Win XP SP2.
Ils parlent de la signature des binaires. Ce n'est pas indispensable pour qu'un programme fonctionne, même si bien sûr c'est préférable du point de vue sécurité.
-
Avoir une collision n'est pas suffisant : il faut encore que la collision trouvé soit valide
Pour des images par exemple, c'est plus facile : il y a plein de données "peu ou pas visible" qui peuvent être donc modifiées pour obtenir une collision
Avec des certificats, il faut que la collision soit un certificat valide
-
Avoir une collision n'est pas suffisant : il faut encore que la collision trouvé soit valide
Pour des images par exemple, c'est plus facile : il y a plein de données "peu ou pas visible" qui peuvent être donc modifiées pour obtenir une collision
Avec des certificats, il faut que la collision soit un certificat valide
Avec n'importe quel format complexe (HTML, PDF, PS, executable...) tu as plein de place pour du rembourrage sans fonction.
Obtenir une collision ne suffit pas évidemment, il faut une collision entre deux jumeaux dont un est maléfique. Il faut donc que les deux textes soient bien formés par rapport à une norme et que l'un inspire confiance.
-
it's done!
Google a cassé SHA-1:
http://shattered.io/ (démo de 2 documents pdf ayant le meme SHA-1).
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
On aura les détails dans 90 jours après le délai usuel pour rendre public ce genre de chose.
On suspect la NSA d'avoir fait cela avant Google mais comme la NSA ne communique pas sur ce genre de chose ...
-
Mes frères, SHA-1 est déprécié et cassé, réutilisez et vénérez le Saint RC4.
-
Ce n'est pas encore à la portée du premier venu ;)
6,500 years of CPU computation to complete the attack first phase
110 years of GPU computation to complete the second phase
-
Autrement dit, peanuts :)
Multiprocess dude;
-
La collision avec les deux fichiers démo :
$ sha1sum shattered-?.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
$ md5sum shattered-?.pdf
ee4aa52b139d925f8d8884402b0a750c shattered-1.pdf
5bd9d8cabc46041579a311230539b8d1 shattered-2.pdf
$ sha256sum shattered-?.pdf
2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0 shattered-1.pdf
d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff shattered-2.pdf
-
Mes frères, SHA-1 est déprécié
STOP!
Merci de ne pas dire ce genre de choses! Les cuistres vont la recopier et me ressortir et il faudra que j'explique à des gens qui ne connaissent pas le millième de ce que je sais que non, l'usage de SHA1 dans le code de SMF n'est pas devenu une vulnérabilité aujourd'hui et que oui, face à moi ils feraient mieux de la boucler (been there, done that concernant MD5).
L'usage de SHA1 pour l'authentification par signature numérique est déprécié, et de façon générale l'usage pour comparer des fichiers est déprécié.
L'usage de SHA1 pour protéger les mots de passe n'est moins sûr aujourd'hui qu'hier.
-
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
-
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.
-
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 :o ? ;D
-
Tu utilises des algo de hash pour de la crypto :o ? ;D
Certes, et toi aussi : le certificat de lafibre.info utilise sha1 et sha256, par exemple (j'imagine que le premier est conservé pour retrocompabilité)
-
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:
(http://i.imgur.com/K34h8v3.png)
et le verification se fait comme ca:
(http://gsa.github.io/piv-guides/img/certificatechain_small.png)
-
Tu utilises des algo de hash pour de la crypto :o ? ;D
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).
-
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!
-
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
-
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
-
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?
-
Comparaison de fichiers
-
Quels fichiers? Dans quel contexte?
-
Les gens sérieux utilisent les hash pour trouver des potentiels match :)
Une vérification bit à bit s'impose par la suite
Donc par exemple un logiciel de sauvegarde distant doit télécharger tous les fichiers au lieu de tous les hash!
-
Les logiciels dont tu parles ne se basent pas que sur le hash
Si je prends rsync par exemple, il faut que le nom du fichier soit le même, mais également la taille, les temps stockés avec l'inode etc
-
Ah oui, alors à quoi sert le hash?
Et de quel logiciel voulais-tu parler?
-
Ah oui, alors à quoi sert le hash?
Pour rsync, le hash c'est MD5, et il n'est pas applique aux fichiers entiers, mais aux blocs de 16K (changeable).
Si tu veux t'assurer de la "securite" de la sauvegarde rsync, tu passes 2 fois, avec des tailles de bloc differentes (et option "force checksum" active - sinon nom+taille+attributes sidentiques -> fichiers identiques).
-
$ sha1sum shattered-?.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
$ md5sum shattered-?.pdf
ee4aa52b139d925f8d8884402b0a750c shattered-1.pdf
5bd9d8cabc46041579a311230539b8d1 shattered-2.pdf
Ok, les choses sont claires, next.....
Rigolade apart, ca fait depuis la nuit des temps qu'on dit de ne pas mettre tous les oeufs dans le meme pannier, et que dans les reseaux et systemes on parle de redondance. Cote securite n'ont ils pas encore bien appris les lecons ? Parce-que avoir deux blobs avec le meme hash pour une fonction bien precise, c'est clair que ce n'est qu'une question de temps (que ca soit 5 minutes ou 5 ans), mais avoir deux blobs qui ont le meme hash pour deux (ou plusieurs) fonctions, je crois qu'on est bien loin....
Comme variotion, il y a aussi le fait de faire un hash sur le blob/fichier original, puis un hash (meme ou autre fonction) sur le fichier + info supplèmentaire.... Bonjour aux collisions qui donnet des hash identiques dans 2 cas ......
-
Rigolade apart, ca fait depuis la nuit des temps qu'on dit de ne pas mettre tous les oeufs dans le meme pannier, et que dans les reseaux et systemes on parle de redondance. Cote securite n'ont ils pas encore bien appris les lecons ? Parce-que avoir deux blobs avec le meme hash pour une fonction bien precise, c'est clair que ce n'est qu'une question de temps (que ca soit 5 minutes ou 5 ans), mais avoir deux blobs qui ont le meme hash pour deux (ou plusieurs) fonctions, je crois qu'on est bien loin....
Ah ah ah, trop drôle. En fait tu viens de dire que tu serais meilleurs en fonction de hachage que les meilleurs cryptographes - et tu ne sais probablement pas que tu viens de dire ça.
-
Vous mélangez un peu les usages la. y'a hashage pour crypto et hashage pour d'autres usages. Git par exemple ce n'est pas pour des raisons de crypto.
Apres cela n’empêche pas d'être problématique, par exemple le serveur SVN de Webkit a été planté gravement quand quelqu'un a envoyé ces 2 fichiers PDF ayant le meme hash SHA-1 dedans...: on n'est pas en crypto mais on a un probleme de sécurité car quelqu'un qui a les droits peut 'planter' (DoS) ou corrompre un dépôt de sources (mais bon apres quelqu'un qui a les droits 'commit' est censé être responsable de ses actes :) )
-
Ah ah ah, trop drôle. En fait tu viens de dire que tu serais meilleurs en fonction de hachage que les meilleurs cryptographes - et tu ne sais probablement pas que tu viens de dire ça.
Effectivement trop drole.
Chercheur en cryptographie = creation et/ou mise a mort des algorithmes de chiffrage et /ou hash.
Utilisateur de cryptographie = utilise les fonctions crees par les precedents pour des applications "vie reele" (enfin, plus ou moins reele).
Moi, je suis de la deuxieme categorie. Je ne suis pas expert en cryptographie, mais je suppose que n'importe quel vrai expert pourra me confirmer qu'utiliser 2 fonctions ou la meme fonction applique 2 fois sur 2 sets de donnnes dont on connait precisement les differences, ca augmente la complexite de facon exponentielle. Tu n'as plus 160 bits de digest, mais 320. A moins d'avoir a la base une(des) fonction(s) vraiment pourrie(s) (et ni SHA-1, ni MD5 ne sont pas si pourries que ca - ils sont juste sujet a certains faiblesses), ca fait exploser fortement le cout pour trouver une (double) collision.
Donc non, je ne dis pas que je suis mieux que les cryptographes, je dis juste que le temps de tout remplacer par SHA-de-la-mort-qui-tue (SHA-2 ??? 256 ??? 512 ??? SHA-3 avec digest de 1024 ????) SHA-1 reste encore utilisable...
Je dis aussi que les reactions style "faut exterminer toute trace de SHA-1" sont completement debiles. Il y a encore des application pour lesquels meme MD5 est amplement sufissant.
-
Vous mélangez un peu les usages la. y'a hashage pour crypto et hashage pour d'autres usages. Git par exemple ce n'est pas pour des raisons de crypto.
Ah bon, un hachage crypto c'est pas crypto?
-
Moi, je suis de la deuxieme categorie. Je ne suis pas expert en cryptographie, mais je suppose que n'importe quel vrai expert pourra me confirmer qu'utiliser 2 fonctions ou la meme fonction applique 2 fois sur 2 sets de donnnes dont on connait precisement les differences, ca augmente la complexite de facon exponentielle.
Non, pas forcèment.
Tu n'as plus 160 bits de digest, mais 320.
Oui, et?
A moins d'avoir a la base une(des) fonction(s) vraiment pourrie(s) (et ni SHA-1, ni MD5 ne sont pas si pourries que ca - ils sont juste sujet a certains faiblesses), ca fait exploser fortement le cout pour trouver une (double) collision.
Pas forcèment.
Encore une fois, si tu penses être capable de concevoir une fonction de hachage plus robuste, vas-y. Là tu laisses entendre que tu ferais mieux que des experts qui ont juste passé des décennies sur le sujet.
Donc non, je ne dis pas que je suis mieux que les cryptographes, je dis juste que le temps de tout remplacer par SHA-de-la-mort-qui-tue (SHA-2 ??? 256 ??? 512 ??? SHA-3 avec digest de 1024 ????) SHA-1 reste encore utilisable...
Oui, mais pour quels usages?
Je dis aussi que les reactions style "faut exterminer toute trace de SHA-1" sont completement debiles. Il y a encore des application pour lesquels meme MD5 est amplement sufissant.
C'est précisèment ce que j'ai expliqué!
-
Les gens sérieux utilisent les hash pour trouver des potentiels match :)
Une vérification bit à bit s'impose par la suite
J'ai cité pleins d'usages de hash qui supposent qu'une telle vérification n'est jamais nécessaire.
Tu peux me dire comment tu proposes de faire?
-
Effectivement trop drole.
Chercheur en cryptographie = creation et/ou mise a mort des algorithmes de chiffrage et /ou hash.
Utilisateur de cryptographie = utilise les fonctions crees par les precedents pour des applications "vie reele" (enfin, plus ou moins reele).
Moi, je suis de la deuxieme categorie. Je ne suis pas expert en cryptographie, mais je suppose que n'importe quel vrai expert pourra me confirmer qu'utiliser 2 fonctions ou la meme fonction applique 2 fois sur 2 sets de donnnes dont on connait precisement les differences, ca augmente la complexite de facon exponentielle. Tu n'as plus 160 bits de digest, mais 320. A moins d'avoir a la base une(des) fonction(s) vraiment pourrie(s) (et ni SHA-1, ni MD5 ne sont pas si pourries que ca - ils sont juste sujet a certains faiblesses), ca fait exploser fortement le cout pour trouver une (double) collision.
Donc il suffirait de combiner des méthodes de hachage trouées pour en faire une bonne?
Voyons voir. Soit n un entier pas trop grand mais pas trop petit, je prends
s_n(M) = SHA1(n || M)
s(M) = s_0(M) || ... || s_n(M)
ou mieux :
s'(M) = SHA1(s(M))
C'est pas beau ça? J'ai fabriqué un hachage fort comme n fois SHA1. Cela devrait faire exploser la difficulté, non?
Donc non, je ne dis pas que je suis mieux que les cryptographes,
Je serais à ta place, je dirais que j'ai humilié les cryptographes.
En quoi les cryptographes ne sont pas humiliés par tes idées?
je dis juste que le temps de tout remplacer par SHA-de-la-mort-qui-tue (SHA-2 ??? 256 ??? 512 ??? SHA-3 avec digest de 1024 ????) SHA-1 reste encore utilisable...
Il reste utilisable pour les preuves de travail, donc comme base de Bitcoin (pour fabriquer la gabegie de ressources qu'est Bitcoin à la base).
-
Vous mélangez un peu les usages la. y'a hashage pour crypto et hashage pour d'autres usages. Git par exemple ce n'est pas pour des raisons de crypto.
Pas là pour raison de crypto, vraiment?
Apres cela n’empêche pas d'être problématique, par exemple le serveur SVN de Webkit a été planté gravement quand quelqu'un a envoyé ces 2 fichiers PDF ayant le meme hash SHA-1 dedans...: on n'est pas en crypto mais on a un probleme de sécurité car quelqu'un qui a les droits peut 'planter' (DoS) ou corrompre un dépôt de sources (mais bon apres quelqu'un qui a les droits 'commit' est censé être responsable de ses actes :) )
être responsable de ses actes = ne pas utiliser des fichiers ayant une valeur SHA1 commune?
;)
Puisque SHA1 est "pas pour des raisons de crypto", alors avoir une tel cas n'est pas une attaque sur la crypto, donc le dév n'a rien à se reprocher.
-
Ok, les choses sont claires, next.....
Rigolade apart, ca fait depuis la nuit des temps qu'on dit de ne pas mettre tous les oeufs dans le meme pannier, et que dans les reseaux et systemes on parle de redondance. Cote securite n'ont ils pas encore bien appris les lecons ?
La leçon est de ne pas utiliser de technologie dépassée, pas d'empiler les planches pourries!
Parce-que avoir deux blobs avec le meme hash pour une fonction bien precise, c'est clair que ce n'est qu'une question de temps (que ca soit 5 minutes ou 5 ans), mais avoir deux blobs qui ont le meme hash pour deux (ou plusieurs) fonctions, je crois qu'on est bien loin....
J'espère que tu n'utilises JAMAIS la crypto pour quoi que ce soit d'important, puisque "ce n'est qu'une question de temps (que ca soit 5 minutes ou 5 ans)" avant qu'elle soit cassée.
Comme variotion, il y a aussi le fait de faire un hash sur le blob/fichier original, puis un hash (meme ou autre fonction) sur le fichier + info supplèmentaire.... Bonjour aux collisions qui donnet des hash identiques dans 2 cas ......
Quelle info supplèmentaire?
Si tu utilises des informations sans lien avec le contenu du fichier, tu ne mesures plus le contenu.
Ce que tu dis manque totalement de logique!