mercredi 15 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de tfe :

[12/09@13:17] Patchez firefox ! (beta)
[16/08@08:11] ami buveur de biere, tu vas faire fortune !
[29/06@10:32] google earth
[01/05@10:23] 2.6.11.8
[29/04@09:11] Firefox supportant le SVG (sous windows) ?
[29/12@14:11] Jesuislibre.org bug
[19/12@22:16] Microsoft fait du css?
[09/12@23:38] Failles multiples pour plusieurs navigateurs
[02/05@09:35] firefox et xpdf ?
[27/04@10:10] giga! byte
[22/04@10:46] IBM se lance dans la course aux DRM
[20/03@19:03] Dur dur!
[17/03@13:38] http://www.branchez-vous.com/actu/04-03/08-174901.html
[12/03@07:05] bill gates attaqué par l' armée !
[02/03@22:10] Stand blog?
[22/02@16:05] Appel a temoin !
[21/02@19:03] Publicité
[17/02@19:29] amsn cvs
[10/02@20:08] re Update de windows discrète
[05/02@22:38] firebird 0.8

Journal : md5 (encore) mis à mal

Posté par tfeserver tfe (page perso, ) le 23 septembre 2005

Ben voila, tout est dans le titre.
Un petit gars qui programme en C# a codé des petits programmes permettant de camoufler 2 binaires dans un fichier ayant le même md5.
L'article: http://www.codeproject.com/useritems/HackingMd5.asp(...)

un commentaire sur slashdot interessant:
deux pages html avec le meme md5:
http://www.doxpara.com/t1.html(...)
http://www.doxpara.com/t2.html(...)

c'est bluffant (si on regarde pas le code source).

> Lire le journal (25 commentaires, moyenne: 5,4).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

slashdot

Posté par baud123 (Jabber id, page perso, ) le 23/09/2005 à 12:09. (lien). Évalué à 4.

l'article sur slashdot : http://it.slashdot.org/it/05/09/23/0618252.shtml?tid=172&tid=93(...)

C'est un exemple de collision de hash (j'ai pas trop bien compris tes explications) : en gros 2 ISOs pourraient avoir le même md5sum.

Ceci est aussi possible avec RSA (un peu plus dur néanmoins) je crois (chercher RSA-200), ou je confonds tout...

[^]Re: slashdot

Posté par seedeexeen () le 23/09/2005 à 12:28. (lien). Évalué à 10.
Je ne vois pas ce qu'il y a de bluffant. c'est un peu le principe des hash.
Si tu trouves un algo de hash sans collision alors cela signifie que tu as une bijection entre ton message et ton hash. Cet algo te permet donc de reconstruire le message de départ d'après le hash.
Et là t'as trouvé un super algo de compression ;-)
- [^]Re: slashdot
  
  Posté par Laurent Saint-Michel () le 23/09/2005 à 12:48. (lien). Évalué à 10.
  ou un hash de grosse taille
- [^]Re: slashdot
  
  Posté par Tom Debruyne (page perso, ) le 23/09/2005 à 13:42. (lien). Évalué à 10.
  Le problème n'est pas qu'il soit possible de trouver une collision, mais que ceci soit possible sans utiliser la force brute, autrement dit, dans un laps de temps raisonnable.
  
  Tom
  - [^]Re: slashdot
    
    Posté par fmaz fmaz () le 23/09/2005 à 14:00. (lien). Évalué à 10.
    En fait, il faut même plus pour que ce soit intéressant.
    
    Que toto.c ait un hash commun avec
    un truc plus ou moins aléatoire, ce n'est pas bein grave.
    
    Là où ça peut devenir génant, c'est si on arrive à provoquer
    des collitions entre
    
    toto.c et toto_backdoor.c
    - [+] [^]Re: slashdot
      
      Posté par chx dein (page perso, ) le 23/09/2005 à 14:20. (lien). Évalué à -9.
      Commentaire tout à fait pertinent.
    - [^]Re: slashdot
      
      Posté par Éric (Jabber id, page perso, ) le 23/09/2005 à 15:50. (lien). Évalué à 2.
      C'est ce qu'il se passe ici, enfin presque : on fait un toto.exe et un toto_backdoor.exe
    - [^]Re: slashdot
      
      Posté par hervé Couvelard (Jabber id, page perso, ) le 23/09/2005 à 15:59. (lien). Évalué à 8.
      En fait oui, on peut 'facilement', mais pour faire cela, il faut être l'auteur de toto.c
      
      De ce que j'ai lu, il y a une 'entête particulière' qui doit être mis dans toto.c et toto_backdoor.c pour que cela fonctionne, ce qui limite un peu tout de même la porté de la chose, et du fait c'est 'reconnaissable' par 'signature'. en effet le nombres de "vecteur" qui font collisions ne sont pas infini, et ils ne sont pas facile à trouver.
    - [^]Re: slashdot
      
      Posté par jcs (page perso, ) le 23/09/2005 à 21:35. (lien). Évalué à 5.
      Que toto.c ait un hash commun avec un truc plus ou moins aléatoire, ce n'est pas bein grave.
      
      L'attaque utilisée ne produit pas un machin aléatoire mais deux fichier très proches. En fait on utilise un propriété de md5 (appelée length extension) qui ne fait que seul le début des fichiers est différent. L'objectif est de produire deux fichiers du genre : si (X) alors A sinon B où seul X varie pour donner soit A, soit B.
      
      Un des risque est d'obtenir des signatures identiques sont des fichiers très différent. Par exemple, on produit deux fichiers avec le même md5 l'un contenant Je donne 1.000.000¤ à Toto et l'autre Toto me donne 1.000.000¤. Je fais signer le 1er message à Toto avec une signature (par exemple RSA/Md5). Puis je vais voire un notaire mais avec le 2e fichier, la signature est aussi valable. Bien sûr c'est complètement théorique puisque avec l'attaque actuelle un examen des fichiers montrerait la supercherie.
      
      Pour info : deux fichiers postscript aec le même hash md5 mais au contenus bien différents : http://www.cits.rub.de/MD5Collisions/(...)
      
      Pour la petite histoire, l'attaque a été publiée il y a plusieurs mois par une équipe de cryptographes chinois qui avait mal implémenté le md5. Le premier papier publié cassait en fait un algo proche de md5 mais avec un problème d'endianness. Une version corrigée du papier a ensuite été publié quelques heures plus tard.
      
      --
      Hurd will be out in a year (or two, or next month, who knows)
      -- Linus Benedict Torvalds, 1991

Comme répété auparavant

Posté par lezardbreton (Jabber id, page perso, ) le 23/09/2005 à 12:16. (lien). Évalué à 10.

Le md5 est surtout utilisé actuellement pour vérifier qu'un transfert s'est fait correctement. Il ne sert normalement pas à authentifier l'origine ou à certifier que le fichier est sûr.

[^]Re: Comme répété auparavant

Posté par tfeserver tfe (page perso, ) le 23/09/2005 à 12:37. (lien). Évalué à 9.
il est tres utilise malheureusement pour la verification des mot de passe aussi...
- [^]Re: Comme répété auparavant
  
  Posté par ashram4 () le 23/09/2005 à 12:47. (lien). Évalué à 10.
  a zut j'avais oublié cette application de MD5 mais ça change rien à la situation actuelle puisque pour trouver une séquence avec le même MD5sum il faut en essayer plusieurs donc ça revient à faire une attaque par force brute ce qui peut être très long.
  
  Je n'ai pas lu comment trouver 2 séquences défférentes avec le même MD5sum il y a une méthode particulière ou faut essayer toutes les possibilités? si il y a une méthode c'est peut être plus rapide que la force brute mais encore faut t'il avoir la séquence de départ donc une situation peu probable quand on cherche un mot de passe.

idée amusante mais...

Posté par ashram4 () le 23/09/2005 à 12:38. (lien). Évalué à 5.

ça ne change pas grand chose au statut de MD5. Un gars a démontré qu'il existe des collision MD5 mais elles ne sont pas facile à trouver, la preuve il n'en fourni qu'une. ça prouve que MD5 n'est pas sûr pour une fonction de sécurité mais en tant que fonction de vérification d'intégrité des données elle garde tout son sens : la probabilité que 2 fichiers différents produise le même hachage MD5 est très faible dont lorsqu'un système d'installation installe un programme il utilise MD5 pour s'assurer que le fichier utilisé est correctement récupéré (intégrité des donnée) mais il ne donne aucune garantie sur l'origine du fichier (il y a GPG pour ça ).

En plus dans l'exemple décrit il faut que le pirate fournisse un installateur modifié et 2 archives qui contiennent chacunes le bon programme et le mauvais programme. Quel est l'intérêt pratique (ok c'est un bon exercice intellectuel) de diffuser une archive qui contient un code malveillant non activé puis ensuite une autre avec le code malveillant activé? autant directement diffuser l'archive avec le code malveillant.

[^]Re: idée amusante mais...

Posté par harbort1 () le 23/09/2005 à 15:24. (lien). Évalué à 6.
la probabilité que 2 fichiers différents produise le même hachage MD5 est très faible

Non ! Le principe du hash de fichier n'est pas là !

Le but est d'obtenir une fonction pour laquelle :
1 - toutes les valeurs sont équiprobables
2 - le hash de deux fichiers peu différents impliquent des valeurs très différentes

Mais rien n'est dis dans le cas où les fichiers sont très différents, tout simplement parce qu'on essaie de résumer des centaines de Mo en qq octets, et il est illusoire de dire qu'il n'existe pas (ou même qu'il n'y a pas bcp) de fichiers ayant le même hash.

Du coup, les attaques sont à rechercher dans les fichiers très différents ...
- [^]Re: idée amusante mais...
  
  Posté par gnap gnap (page perso, ) le 23/09/2005 à 15:36. (lien). Évalué à 4.
  Les attaques sont surtout à rechercher dans les fichiers spécialement préparés pour l'occasion.
  
  L'exemple suivant le montre très bien http://www.cits.rub.de/MD5Collisions/(...)
  
  Les fichiers concernés ne sont pas très différents.
  
  Par contre, ils n'ont pas la même taille. Il s'impose donc, quand on base des verifs sur le md5, de ne pas oublier de vérifier la taille du fichier.

oui mais

Posté par Éric (Jabber id, page perso, ) le 23/09/2005 à 12:39. (lien). Évalué à 10.

oui mais si j'ai bien compris l'article il ne s'agit pas de trouver une collision avec un fichier existant mais à partir d'un fichier en trouver deux autres qui sont en collision.

Tu as au départ une source S1, tu as à l'arrivée une source S2 et une collision C. S1 et S2 n'ont pas la même taille ni le même hash.

La conséquence :
- ça ne permet pas de pervertir un fichier qui a déjà été distribué par un tiers (puisque S1 != S2 et avec des hash différents)
- ça n'est pas extensible à tous les formats ou toutes les données (dans un exe il est facile de rajouter des bits morts, dans d'autres formats c'est impossible ou limité)
- ca ne permet pas de fausser les mots de passe gérés avec un algo basé sur md5

Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).
Reste aussi que même dans les formats où c'est possible de rajouter des bits morts pour générer la collision, il n'est pas impossible que ce soit visible (pour ceux qui savent comment est fait un binaire, je pense qu'il doit être visible qu'un gros flot d'octet est inutilisé à la fin).

[^]Re: oui mais

Posté par Matthieu MARC () le 23/09/2005 à 19:33. (lien). Évalué à 2.
Ce que ça permet c'est par contre préparer un code méchant et un code gentil, diffuser le gentil, puis plus tard, l'air de rien, diffuser le méchant pendant un ou deux jours sans changer le md5. Ca demande quand même une mauvaise foi sur le distributeur initial dès le départ (ce qui n'empeche pas que ce soit gênant, on est d'accord).

Heu, c'est tout de même inquiétant ! On peut imaginer que dans quelques temps des éditeurs de sécurité en mal d'idée, ayant vendu des firewalls et des antivirus à tout le monde se disent qu'ils peuvent faire plus d'argent en vendant également des vérificateurs d'intégrité du système à la tripwire. L'utilisateur lambda se sent en sécurité.
D'un autre côté, on a un éditeur A qui vend un logiciel. Le logiciel est enregistré par le vérificateur d'intégrité. Sauf que A avait trifouillé son logiciel pour pouvoir par la suite faire des modifications tout en by-passant le vérificateur d'intégrité. Du genre A dit: "bon, maintenant, c'est fini le piratage, maintenant nos logiciels envoient des informations à nos serveurs pour vérification". Et bah, l'utilisateur lambda il se dira : "dans ses rêves ! m'en fous, mon vérificateur d'intégrité me dira si son logiciel change ! j'suis tranquille !"

Bref, scénario catastrophe. Mais bon même si ça a une probabilité de 1% de se produire, faut pas l'oublier !
- [^]Re: oui mais
  
  Posté par Éric (Jabber id, page perso, ) le 23/09/2005 à 20:15. (lien). Évalué à 2.
  Oui oui. En même temps :
  - si c'est du close source y'a pas besoin de changer le soft pour faire ça, suffit que la fonctionnalité soit déjà présente et qu'elle ne soit qu'activée par la suite (par rapport à une date par exemple). Le hash n'a pas changé, le soft n'a pas changé, pas besoin de collision md5.
  - si c'est de l'open source on verra des trucs bizarres dans les sources
  
  - dans tous les cas annexer la taille au md5 (chose qu'on vérifie souvent) montrera le problème.
  
  Ceci dit oui, c'est inquiétant.

Même hash et même taille ?

Posté par andeus () le 23/09/2005 à 12:42. (lien). Évalué à 8.

Le même hash Ok, mais le même hash et la même taille de fichier ça paraît plus difficile.

[^]Re: Même hash et même taille ?

Posté par L () le 23/09/2005 à 15:41. (lien). Évalué à 4.
Pire admettons que le second fichier a la même somme de contrôle MD5 et la même taille, je doute qu'il soit possible d'obtenir facilement un fichier de même nature. Par exemple, si le fichier original est un binaire et que la pâle copie contient des données aléatoires, l'intérêt de l'exploit est quasiment nul vu que la copie ne servira à rien.

On pourrait se dire que l'intérêt de l'existence d'une collision pourrait peut-être être mathématique : même pas ! Un étudiant de première saurait qu'il existe des collisions : avec une sommes de contrôle de 32 caractères ayant 16 possibilités de valeurs ([0-9,A-F]{32]), même si le nombre de possibilité est énorme (16^32), on ne peut mathématiquement pas représenter une somme unique pour tous les fichiers passés, existants et futurs.

De toute façon, on n'a qu'à passer à sha1sum et le problème est réglé pour quelques temps non ? :)
- [^]Re: Même hash et même taille ?
  
  Posté par shal () le 23/09/2005 à 18:19. (lien). Évalué à 4.
  "De toute façon, on n'a qu'à passer à sha1sum et le problème est réglé pour quelques temps non ? :)"
  
  Heuu non..... SHA1 est en passe d'etre atomisé aussi. Pour l'instant il tiens par des bouts de ficelle. on en est a du 2^69 (je crois) donc atteignable par un ordi.
  
  Actuellement c'est un peu la panic chez les crypto (enfin autant que ca peut être la planic chez des universitaires ;-) ). Ils sont en train de se mettre a rechercher un nouveau algo de hash car tous les autres vont tomber a plus ou moins long terme
  - [^]Re: Même hash et même taille ?
    
    Posté par L () le 23/09/2005 à 18:58. (lien). Évalué à 3.
    Tu veux dire qu'il existe des exemples pertinents de collision SHA1 ? Quand je dis pertinent, je ne parle pas de ce qu'on nous montre actuellement pour MD5 avec des données aléatoires qui ne représentent aucune structure de données utiles !
    
    Au pire, il reste toujours la solution de combiner les deux algorithmes SHA1 (sha1sum) et MD5 (md5sum) : il suffit de générer deux sommes de contrôle, l'une avec l'algorithme MD5 et l'autre avec l'algorithme SHA1 pour un fichier donné. Ça devrait repousser le faux-problème des collisions aux calendes grecques et ça occupera encore nos mathématiciens pour quelques bonnes années.
    
    Sinon, il reste la solution la plus sûre actuellement : signer les fichiers avec GPG. L'avantage de GPG est qu'en plus de l'intégrité des données, on s'assure de leur authenticité.
    - [^]Re: Même hash et même taille ?
      
      Posté par Gof (Jabber id, page perso, ) le 23/09/2005 à 19:23. (lien). Évalué à 2.
      «Sinon, il reste la solution la plus sûre actuellement : signer les fichiers avec GPG. »
      
      Si mes souvenirs sont bons, GPG utilise lui même le SHA1 ou un autre hash du même style, ce n'est donc pas une solution
      - [^]Re: Même hash et même taille ?
        
        Posté par briaeros007 () le 23/09/2005 à 19:37. (lien). Évalué à 2.
        effectivement gpg est basé sur des fonctions de hashages standart ; donc il ne depend pas que de sha1.
        gpg est un outil de chiffrement pas de hash .
        
        Quand aux autres fonctions de hash crypto forte (> à 2^80) on en connais : ripemd160 , whirlpool, sha-256 et > etc...
        
        --
        Subete ga wakatta toki…watashi ga anta wo korosu.
        
        [^]Re: Même hash et même taille ?
        
        Posté par jcs (page perso, ) le 23/09/2005 à 21:09. (lien). Évalué à 4.
        Le problème c'est que concernant les autres fonctions de hash, soit elles n'ont été que peu étudiées (ripemd, whirlpool...) et par conséquent on a peu d'infos sur de potentielles attaques, soit elles commencent à avoir du plomb dans l'aile. On a désormais une attaque réaliste sur sha1, sha-256, sha-384 et sha-512 tiennent encore mais pour combien de temps ? C'est pour cette raison de la communauté des cryptographes s'est soudain senti ces derniers mois une nouvelle passion pour les algos de hash.
        
        --
        Hurd will be out in a year (or two, or next month, who knows)
        -- Linus Benedict Torvalds, 1991

Revenir en haut de page

Journal : md5 (encore) mis à mal

slashdot

[^]Re: slashdot

[^]Re: slashdot

[^]Re: slashdot

[^]Re: slashdot

[+] [^]Re: slashdot

[^]Re: slashdot

[^]Re: slashdot

[^]Re: slashdot

Comme répété auparavant

[^]Re: Comme répété auparavant

[^]Re: Comme répété auparavant

idée amusante mais...

[^]Re: idée amusante mais...

[^]Re: idée amusante mais...

oui mais

[^]Re: oui mais

[^]Re: oui mais

Même hash et même taille ?

[^]Re: Même hash et même taille ?

[^]Re: Même hash et même taille ?

[^]Re: Même hash et même taille ?

[^]Re: Même hash et même taille ?

[^]Re: Même hash et même taille ?

[^]Re: Même hash et même taille ?