A quoi sert ce groupe si l'annonce d'un truc de ce genre met plusieurs
jours pour y arriver ? Tss.
Une collision a été trouvé sur SHA-0 en utilisant un algo de Antoine
Joux (une amélioration de ses résultats de 98 avec Chabaud qui utilise
aussi une technique de Biham et Chen sur les "neutral bit") :
http://www.mail-archive.com/cryptography@metzdowd.com/msg02554.html
Valeur de haché commune :
c9f160777d4086fe8095fba58b7e20c228a4006b
Il suffit de faire "openssl sha file.bin" sur un fichier binaire dont le
contenu est l'un de deux précédent pour reproduire le résultat.
Rapellons que SHA-0 est la première version de l'algorythme SHA, qui a
été précipitament retiré par le NSA suite à la découverte d'une
faiblesse que le NSA n'a jamais publié.
L'attaque a pris environ 80 000 heures CPU sur le système TERA NOVA (256
Intel-Itanium2 de BULL SA, installé au labo TERA TECH du CEA DAM).
La complexité de l'attaque est estimé à 2^51.
Apparement, ce système n'est pas listé dans le top 500 des
super-ordinateurs de 2004.
Ou bien s'agit-il en fait de l'ordinateur de Bull classé 227ème dont la
description ressemble fortement ?
A quoi sert ce groupe si l'annonce d'un truc de ce genre met plusieurs jours pour y arriver ? Tss.
Comme tu dis Tsss ... ! Beau boulot en tout cas.
Jean-Marc Desperrier
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Voir le papier de Eric Rescorla qui donne une archive à télécharger pour reproduire : md5coll.tar.gz . http://www.rtfm.com/movabletype/archives/2004_08.html#001053
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Personne ne pense qu'il serait plus difficile de casser le vrai md5 que celui-là, apparement la seule raison de cette inversion est une erreur d'implémentation des auteurs. C'est vrai que la RFC du MD5 est peu claire sur ce point, elle écrit "word A: 01 23 45 67", mais il faut bien lire qu'il y a écrit avant "low-order bytes first", mais c'est curieux de ce lancer dans quelque chose comme cela sans même tester son implémentation.
Les commentaires analysent assez peu l'attaque.
L'article écrit qu'elle consiste de trouver un couple de bloc M'k et M'ki qui vérifie une certaine propriété, et que ensuite on peut trouver très rapidement des paires de bloc complémentaire Ni et N'i tels que : MD5(M,Ni) = MD5(M',N'i) (',' désigne la concaténation)
Le papier écrit que la propriété à vérifier pour M'k/M'ki est :
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne. Mais je ne prétend pas être un expert en crypto :-)
Ils expliquent ensuite pour les autres fonctions de hachage que c'est à chaque fois une équation du même type mais avec des paramètre modifiés qui permet de trouver les bons blocs. D'où la conclusion qu'effectivement, ils n'auront aucun problème à corriger l'attaque pour le vrai MD5.
Les résultats sont énormes : sha-0 cassé à 2^40, Haval-160 en 2^32, md4 à la main, 1 heure de calcul sur un IBM P690 pour md5 ...
Note : Ca peut être très puissant un IBM P690, tout dépend combien de processeurs on assemble. Apparament celui de Shanghai n'est pas listé dans le top 500, mais des P690 y soit présents de la 6ème à la 470ème place.
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage.
Il n'y aura guère que SHA-1 à s'en sortir indemne.
Voir le papier de Eric Rescorla qui donne une archive à télécharger pour
reproduire : md5coll.tar.gz .
http://www.rtfm.com/movabletype/archives/2004_08.html#001053
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
Personne ne pense qu'il serait plus difficile de casser le vrai md5 que
celui-là, apparement la seule raison de cette inversion est une erreur
d'implémentation des auteurs.
C'est vrai que la RFC du MD5 est peu claire sur ce point, elle écrit
"word A: 01 23 45 67", mais il faut bien lire qu'il y a écrit avant
"low-order bytes first", mais c'est curieux de ce lancer dans quelque
chose comme cela sans même tester son implémentation.
Les commentaires analysent assez peu l'attaque.
L'article écrit qu'elle consiste de trouver un couple de bloc M'k et
M'ki qui vérifie une certaine propriété, et que ensuite on peut trouver
très rapidement des paires de bloc complémentaire Ni et N'i tels que :
MD5(M,Ni) = MD5(M',N'i) (',' désigne la concaténation)
Le papier écrit que la propriété à vérifier pour M'k/M'ki est :
Aucune explication claire sur la signification de cette équation qui est
très obscure pour ce qui me concerne.
Mais je ne prétend pas être un expert en crypto :-)
Ils expliquent ensuite pour les autres fonctions de hachage que c'est à
chaque fois une équation du même type mais avec des paramètre modifiés
qui permet de trouver les bons blocs.
D'où la conclusion qu'effectivement, ils n'auront aucun problème à
corriger l'attaque pour le vrai MD5.
Les résultats sont énormes : sha-0 cassé à 2^40, Haval-160 en 2^32, md4
à la main, 1 heure de calcul sur un IBM P690 pour md5 ...
Note : Ca peut être très puissant un IBM P690, tout dépend combien de
processeurs on assemble. Apparament celui de Shanghai n'est pas listé
dans le top 500, mais des P690 y soit présents de la 6ème à la 470ème place.
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Voir le papier de Eric Rescorla qui donne une archive à télécharger pour reproduire : md5coll.tar.gz . http://www.rtfm.com/movabletype/archives/2004_08.html#001053
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Personne ne pense qu'il serait plus difficile de casser le vrai md5 que celui-là, apparement la seule raison de cette inversion est une erreur d'implémentation des auteurs. C'est vrai que la RFC du MD5 est peu claire sur ce point, elle écrit "word A: 01 23 45 67", mais il faut bien lire qu'il y a écrit avant "low-order bytes first", mais c'est curieux de ce lancer dans quelque chose comme cela sans même tester son implémentation.
Les commentaires analysent assez peu l'attaque.
L'article écrit qu'elle consiste de trouver un couple de bloc M'k et M'ki qui vérifie une certaine propriété, et que ensuite on peut trouver très rapidement des paires de bloc complémentaire Ni et N'i tels que : MD5(M,Ni) = MD5(M',N'i) (',' désigne la concaténation)
Le papier écrit que la propriété à vérifier pour M'k/M'ki est :
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne. Mais je ne prétend pas être un expert en crypto :-)
Ils expliquent ensuite pour les autres fonctions de hachage que c'est à chaque fois une équation du même type mais avec des paramètre modifiés qui permet de trouver les bons blocs. D'où la conclusion qu'effectivement, ils n'auront aucun problème à corriger l'attaque pour le vrai MD5.
Les résultats sont énormes : sha-0 cassé à 2^40, Haval-160 en 2^32, md4 à la main, 1 heure de calcul sur un IBM P690 pour md5 ...
Note : Ca peut être très puissant un IBM P690, tout dépend combien de processeurs on assemble. Apparament celui de Shanghai n'est pas listé dans le top 500, mais des P690 y soit présents de la 6ème à la 470ème place.
Erwann ABALEA
Bonjour,
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness. Mais j'ai testé leurs couples de messages pour le MD4, et effectivement, on trouve bien le même hash, qui n'est pas celui présenté dans le papier (c'est encore étrange).
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne.
La partie 's=4,11,14' désigne les entiers 32 bits concernés par les modifications (la numérotation commence à 0, donc il s'agit ici des 5è, 12è et 14è entiers 32bits), et le (0,0,0,...) désigne les bits modifiés (là encore, il faut considérer les entiers comme des quantités 32 bits little-endian).
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les modifications indiquées pour le MD4, et je ne trouve pas de collision. J'ai également repris les messages proposés et changé un seul bit, et là non plus, ça ne marche pas.
Mais je ne prétend pas être un expert en crypto :-)
Je pense qu'il faudrait être également bon en Chinois, au moins pour comprendre leur façon de penser ;)
J'attend avec impatience les commentaires...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- - Il n'y a pas de "newsmaster". Ici, c'est un forum libre (aussi libre que puisse être un forum sur la hiérarchier Usenet FR, bien sûr). [...] Réfléchis à cela. -+- V. in GNU : les newsmasters, c'est à (hiérar)chier +-+
Bonjour,
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage.
Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne
s'en sert en pratique...
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes
d'endianness. Mais j'ai testé leurs couples de messages pour le MD4, et
effectivement, on trouve bien le même hash, qui n'est pas celui présenté
dans le papier (c'est encore étrange).
Aucune explication claire sur la signification de cette équation qui est
très obscure pour ce qui me concerne.
La partie 's=4,11,14' désigne les entiers 32 bits concernés par les
modifications (la numérotation commence à 0, donc il s'agit ici des 5è,
12è et 14è entiers 32bits), et le (0,0,0,...) désigne les bits modifiés
(là encore, il faut considérer les entiers comme des quantités 32 bits
little-endian).
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les
modifications indiquées pour le MD4, et je ne trouve pas de collision.
J'ai également repris les messages proposés et changé un seul bit, et là
non plus, ça ne marche pas.
Mais je ne prétend pas être un expert en crypto :-)
Je pense qu'il faudrait être également bon en Chinois, au moins pour
comprendre leur façon de penser ;)
J'attend avec impatience les commentaires...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
- Il n'y a pas de "newsmaster". Ici, c'est un forum libre (aussi libre
que puisse être un forum sur la hiérarchier Usenet FR, bien sûr).
[...] Réfléchis à cela.
-+- V. in GNU : les newsmasters, c'est à (hiérar)chier +-+
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness. Mais j'ai testé leurs couples de messages pour le MD4, et effectivement, on trouve bien le même hash, qui n'est pas celui présenté dans le papier (c'est encore étrange).
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne.
La partie 's=4,11,14' désigne les entiers 32 bits concernés par les modifications (la numérotation commence à 0, donc il s'agit ici des 5è, 12è et 14è entiers 32bits), et le (0,0,0,...) désigne les bits modifiés (là encore, il faut considérer les entiers comme des quantités 32 bits little-endian).
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les modifications indiquées pour le MD4, et je ne trouve pas de collision. J'ai également repris les messages proposés et changé un seul bit, et là non plus, ça ne marche pas.
Mais je ne prétend pas être un expert en crypto :-)
Je pense qu'il faudrait être également bon en Chinois, au moins pour comprendre leur façon de penser ;)
J'attend avec impatience les commentaires...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- - Il n'y a pas de "newsmaster". Ici, c'est un forum libre (aussi libre que puisse être un forum sur la hiérarchier Usenet FR, bien sûr). [...] Réfléchis à cela. -+- V. in GNU : les newsmasters, c'est à (hiérar)chier +-+
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne.
[...]
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les modifications indiquées pour le MD4, et je ne trouve pas de collision. J'ai également repris les messages proposés et changé un seul bit, et là non plus, ça ne marche pas.
L'équation décrirait seulement le couple tiré, et n'a rien à voir avec les critères qui ont permis de le trouver ? C'est pas vraiment ce que l'on croit comprendre dans leur papier, qui reste sybillin.
Mais on est au coeur d'un point essentiel dans cette attaque.
Les fonctions de hachage sont censé parfaitement mélanger les bits de façon à ce que la modification d'un seul bit change totalement le résultat. Or là on n'en modifie que trois, et c'est en en changeant seulement trois qu'on arrive facilement à trouver un complément qui provoque facilement une collision.
Cela me semble donc révéler une faille majeure dans le mélange des bits qu'est censé faire la fonction, faille dont le principe semble en plus s'appliquer à une série d'autres fonctions de hachage.
Soit ces fonctions sont fortement cassés, et ce papier n'est que le début. Soit il existe quelques block "faibles" qui sont mal mélangés, sans que cela soit applicable à la majeure partie des blocs, mais cela ne veut pas dire pour autant qu'on ne puisse pas exploiter avec des conséquence gravissime cette faiblesse même localisée.
Aucune explication claire sur la signification de cette équation qui est
très obscure pour ce qui me concerne.
[...]
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les
modifications indiquées pour le MD4, et je ne trouve pas de collision.
J'ai également repris les messages proposés et changé un seul bit, et là
non plus, ça ne marche pas.
L'équation décrirait seulement le couple tiré, et n'a rien à voir avec
les critères qui ont permis de le trouver ?
C'est pas vraiment ce que l'on croit comprendre dans leur papier, qui
reste sybillin.
Mais on est au coeur d'un point essentiel dans cette attaque.
Les fonctions de hachage sont censé parfaitement mélanger les bits de
façon à ce que la modification d'un seul bit change totalement le résultat.
Or là on n'en modifie que trois, et c'est en en changeant seulement
trois qu'on arrive facilement à trouver un complément qui provoque
facilement une collision.
Cela me semble donc révéler une faille majeure dans le mélange des bits
qu'est censé faire la fonction, faille dont le principe semble en plus
s'appliquer à une série d'autres fonctions de hachage.
Soit ces fonctions sont fortement cassés, et ce papier n'est que le début.
Soit il existe quelques block "faibles" qui sont mal mélangés, sans que
cela soit applicable à la majeure partie des blocs, mais cela ne veut
pas dire pour autant qu'on ne puisse pas exploiter avec des conséquence
gravissime cette faiblesse même localisée.
Aucune explication claire sur la signification de cette équation qui est très obscure pour ce qui me concerne.
[...]
Mais ça ne semble pas suffire. J'ai tiré 64 octets au hasard, effectué les modifications indiquées pour le MD4, et je ne trouve pas de collision. J'ai également repris les messages proposés et changé un seul bit, et là non plus, ça ne marche pas.
L'équation décrirait seulement le couple tiré, et n'a rien à voir avec les critères qui ont permis de le trouver ? C'est pas vraiment ce que l'on croit comprendre dans leur papier, qui reste sybillin.
Mais on est au coeur d'un point essentiel dans cette attaque.
Les fonctions de hachage sont censé parfaitement mélanger les bits de façon à ce que la modification d'un seul bit change totalement le résultat. Or là on n'en modifie que trois, et c'est en en changeant seulement trois qu'on arrive facilement à trouver un complément qui provoque facilement une collision.
Cela me semble donc révéler une faille majeure dans le mélange des bits qu'est censé faire la fonction, faille dont le principe semble en plus s'appliquer à une série d'autres fonctions de hachage.
Soit ces fonctions sont fortement cassés, et ce papier n'est que le début. Soit il existe quelques block "faibles" qui sont mal mélangés, sans que cela soit applicable à la majeure partie des blocs, mais cela ne veut pas dire pour autant qu'on ne puisse pas exploiter avec des conséquence gravissime cette faiblesse même localisée.
WinTerMiNator
"Erwann ABALEA" a écrit dans le message de news:
Bonjour,
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont trompés?
-- Michel Nallino aka WinTerMiNator http://www.chez.com/winterminator (Internet et sécurité: comment surfer en paix) http://www.gnupgwin.fr.st (GnuPG pour Windows) Adresse e-mail: http://www.cerbermail.com/?vdU5HHs5WG
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de
news:Pine.LNX.4.58.0408171725090.4989@shining.seclogd.org...
Bonjour,
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage.
Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne
s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes
d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec
l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont
trompés?
--
Michel Nallino aka WinTerMiNator
http://www.chez.com/winterminator
(Internet et sécurité: comment surfer en paix)
http://www.gnupgwin.fr.st
(GnuPG pour Windows)
Adresse e-mail: http://www.cerbermail.com/?vdU5HHs5WG
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont trompés?
-- Michel Nallino aka WinTerMiNator http://www.chez.com/winterminator (Internet et sécurité: comment surfer en paix) http://www.gnupgwin.fr.st (GnuPG pour Windows) Adresse e-mail: http://www.cerbermail.com/?vdU5HHs5WG
Erwann ABALEA
Bonsoir,
On Tue, 17 Aug 2004, WinTerMiNator wrote:
"Erwann ABALEA" a écrit dans le message de news:
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
Le temps que ça va prendre pour se généraliser n'est pas nul, on est dans la vraie vie. ;)
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont trompés?
Dans leur article, les nombres sont des mots de 32 bits tels que lus par une machine little-endian (un Intel par exemple).
Par exemple, le premier message pour le MD4 commence par '4d7a9c83'. Il faut le prendre comme l'entier 32 bits 0x4d7a9c83 (en C), et lu par une machine little-endian, donc son écriture sur disque donnera la suite d'octets 0x83 0x9c 0x7a 0x4d. Donc écrire que l'octet de poids fort est à gauche ne précise rien, personne n'écrit de nombre avec les chiffres les plus significatifs à droite.
Le fait qu'ils aient attaqué un MD5 avec des constantes d'initialisation 'inversées' est quand même un problème. Et les valeurs de hash qu'ils trouvent en est un autre. Enfin, que tout ça finisse quand même par fonctionner et produire des collisions est presque un miracle. ;)
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de
news:Pine.LNX.4.58.0408171725090.4989@shining.seclogd.org...
On Tue, 17 Aug 2004, Jean-Marc Desperrier wrote:
Tibo wrote:
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD"
http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage.
Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne
s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
Le temps que ça va prendre pour se généraliser n'est pas nul, on est dans
la vraie vie. ;)
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes
d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec
l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont
trompés?
Dans leur article, les nombres sont des mots de 32 bits tels que lus par
une machine little-endian (un Intel par exemple).
Par exemple, le premier message pour le MD4 commence par '4d7a9c83'. Il
faut le prendre comme l'entier 32 bits 0x4d7a9c83 (en C), et lu par une
machine little-endian, donc son écriture sur disque donnera la suite
d'octets 0x83 0x9c 0x7a 0x4d. Donc écrire que l'octet de poids fort est
à gauche ne précise rien, personne n'écrit de nombre avec les chiffres les
plus significatifs à droite.
Le fait qu'ils aient attaqué un MD5 avec des constantes d'initialisation
'inversées' est quand même un problème. Et les valeurs de hash qu'ils
trouvent en est un autre. Enfin, que tout ça finisse quand même par
fonctionner et produire des collisions est presque un miracle. ;)
"Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD" http://eprint.iacr.org/2004/199.pdf
C'est une très mauvais semaine pour les fonctions de hachage. Il n'y aura guère que SHA-1 à s'en sortir indemne.
Et les version étendues de SHA (256, 384, 512). Mais comme personne ne s'en sert en pratique...
Bonsoir,
Justement, on va peut-être s'en servir davantage!
Le temps que ça va prendre pour se généraliser n'est pas nul, on est dans la vraie vie. ;)
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
En fait, dans leur papier, toutes les valeurs numériques ont des problèmes d'endianness.
Ils précisent en fin de leur article que tous leur mots sont en 32 bits avec l'octet de poids le plus significatif à gauche. C'est vrai ou ils se sont trompés?
Dans leur article, les nombres sont des mots de 32 bits tels que lus par une machine little-endian (un Intel par exemple).
Par exemple, le premier message pour le MD4 commence par '4d7a9c83'. Il faut le prendre comme l'entier 32 bits 0x4d7a9c83 (en C), et lu par une machine little-endian, donc son écriture sur disque donnera la suite d'octets 0x83 0x9c 0x7a 0x4d. Donc écrire que l'octet de poids fort est à gauche ne précise rien, personne n'écrit de nombre avec les chiffres les plus significatifs à droite.
Le fait qu'ils aient attaqué un MD5 avec des constantes d'initialisation 'inversées' est quand même un problème. Et les valeurs de hash qu'ils trouvent en est un autre. Enfin, que tout ça finisse quand même par fonctionner et produire des collisions est presque un miracle. ;)
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais le vecteur est absolument standard. Le md5 des deux fichiers de 1024 bits dont le contenu en hexa est:
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais
le vecteur est absolument standard. Le md5 des deux fichiers
de 1024 bits dont le contenu en hexa est:
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais le vecteur est absolument standard. Le md5 des deux fichiers de 1024 bits dont le contenu en hexa est:
Le papier http://eprint.iacr.org/2004/199.pdf a été révisé. Les formules ne sont pas plus claires, les messages sont toujours du little-endian, et les hash fournis ne sont pas ceux calculés. Mais la collision fonctionne sur le vrai MD5.
Reste à comparer les 2 papiers, j'ai conservé le précédent au bureau...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo, modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux accroître la RAM ou faire passer le P II à 450 Mhz ? -+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Le papier http://eprint.iacr.org/2004/199.pdf a été révisé. Les formules
ne sont pas plus claires, les messages sont toujours du little-endian, et
les hash fournis ne sont pas ceux calculés. Mais la collision fonctionne
sur le vrai MD5.
Reste à comparer les 2 papiers, j'ai conservé le précédent au bureau...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo,
modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux
accroître la RAM ou faire passer le P II à 450 Mhz ?
-+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Le papier http://eprint.iacr.org/2004/199.pdf a été révisé. Les formules ne sont pas plus claires, les messages sont toujours du little-endian, et les hash fournis ne sont pas ceux calculés. Mais la collision fonctionne sur le vrai MD5.
Reste à comparer les 2 papiers, j'ai conservé le précédent au bureau...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo, modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux accroître la RAM ou faire passer le P II à 450 Mhz ? -+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Erwann ABALEA
On Tue, 17 Aug 2004, Francois Grieu wrote:
Jean-Marc Desperrier dit:
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais le vecteur est absolument standard. Le md5 des deux fichiers de 1024 bits dont le contenu en hexa est:
Ca dépend. Quelle version du papier as-tu? Dans celle datée du 16 août, les vecteurs sont effectivement inversés. Dans la version révisée du 17 août, ce sont les bons.
est identique: a4c0d35c95a63a805915367dcfe6b751
C'est ce que je trouve aussi avec la version révisée (heureusement).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
On Tue, 17 Aug 2004, Francois Grieu wrote:
Jean-Marc Desperrier <jmdesp@alussinan.org> dit:
La collision est sur une variante de md5 dont le vecteur
d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais
le vecteur est absolument standard. Le md5 des deux fichiers
de 1024 bits dont le contenu en hexa est:
Ca dépend. Quelle version du papier as-tu? Dans celle datée du 16 août,
les vecteurs sont effectivement inversés. Dans la version révisée du 17
août, ce sont les bons.
est identique: a4c0d35c95a63a805915367dcfe6b751
C'est ce que je trouve aussi avec la version révisée (heureusement).
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tu as une vision obsolète du Net. Les groupes sont hébergés chez les
FAI maintenant. Il FAUT que leur gestion change.
-+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
La collision est sur une variante de md5 dont le vecteur d'initialisation est inversé.
Non. Les messages sont pas dans leur ordre habituel, mais le vecteur est absolument standard. Le md5 des deux fichiers de 1024 bits dont le contenu en hexa est:
Ca dépend. Quelle version du papier as-tu? Dans celle datée du 16 août, les vecteurs sont effectivement inversés. Dans la version révisée du 17 août, ce sont les bons.
est identique: a4c0d35c95a63a805915367dcfe6b751
C'est ce que je trouve aussi avec la version révisée (heureusement).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
