j'ai bien trouvé sur internet un machin pour coder le md5 mais par contre,
rien pour décoder ?
quel est l'intérêt supplémentaire d'avoir un truc qui ne marche que dans un
sens ?
comment faire pour une personne A pour envoyer un message md5 que seule une
personne B pourra décoder ?
comment ajouter un modérateur C entre A et B via md5?
le bon raisonnement est que 16 caractères de 16 valeurs codent tous les md5
Non. 16 octets à 256 valeurs possibles, ou 32 caractères à 16 valeurs possibles. Tu viens de te prendre un facteur 2^64 dans la figure. Ca fait mal?
mais bon, la stratégie que je me propose, c'est plutôt de remonter comme un petit poisson au travers du codage du md5, en mettant ses propres variables partout où c'est possible... et les possibilités ne manquent pas...
Tu as appris à programmer la semaine dernière et tu veux donner des leçons à Ronald Rivest? Bien bien bien.
en gros, y a que 4 gros boutons FF(abcd),GG(abcd),HH(abcd) et II(abcd) qui s'intermélangent en créant des boutons FF-(abcd),GG-(abcd),HH-(abcd) et II-(abcd) on s'assure de recréer un source qui correspond digit à digit à celui qui est proposé...
Ca a l'air tellement trivial que je me demande pourquoi tu ne nous proposes pas le code source tout de suite.
ca casserait le md5 mais bien sûr pas le hachage...
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On 18 May 2004 15:23:40 GMT, Eric CHAPUZOT <echap@evhr.net> wrote:
le bon raisonnement est que 16 caractères de 16 valeurs codent tous les
md5
Non. 16 octets à 256 valeurs possibles, ou 32 caractères à 16 valeurs
possibles. Tu viens de te prendre un facteur 2^64 dans la figure. Ca fait
mal?
mais bon, la stratégie que je me propose, c'est plutôt de remonter comme
un petit poisson au travers du codage du md5, en mettant ses propres
variables partout où c'est possible... et les possibilités ne manquent
pas...
Tu as appris à programmer la semaine dernière et tu veux donner des leçons
à Ronald Rivest? Bien bien bien.
en gros, y a que 4 gros boutons FF(abcd),GG(abcd),HH(abcd) et II(abcd)
qui s'intermélangent en créant des boutons FF-(abcd),GG-(abcd),HH-(abcd)
et II-(abcd) on s'assure de recréer un source qui correspond digit à
digit
à celui qui est proposé...
Ca a l'air tellement trivial que je me demande pourquoi tu ne nous
proposes pas le code source tout de suite.
ca casserait le md5 mais bien sûr pas le hachage...
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme
dire que tu connais les horaires des trains mais tu ne sais pas à quelle
heure ils partent...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
le bon raisonnement est que 16 caractères de 16 valeurs codent tous les md5
Non. 16 octets à 256 valeurs possibles, ou 32 caractères à 16 valeurs possibles. Tu viens de te prendre un facteur 2^64 dans la figure. Ca fait mal?
mais bon, la stratégie que je me propose, c'est plutôt de remonter comme un petit poisson au travers du codage du md5, en mettant ses propres variables partout où c'est possible... et les possibilités ne manquent pas...
Tu as appris à programmer la semaine dernière et tu veux donner des leçons à Ronald Rivest? Bien bien bien.
en gros, y a que 4 gros boutons FF(abcd),GG(abcd),HH(abcd) et II(abcd) qui s'intermélangent en créant des boutons FF-(abcd),GG-(abcd),HH-(abcd) et II-(abcd) on s'assure de recréer un source qui correspond digit à digit à celui qui est proposé...
Ca a l'air tellement trivial que je me demande pourquoi tu ne nous proposes pas le code source tout de suite.
ca casserait le md5 mais bien sûr pas le hachage...
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Xavier Roche
Jacques Caron wrote:
C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Euh avec la SNCF, on connait les horaires de trains mais on ne sait jamais quand ils partent. Bon, ok, je sort.
Pour rebondir sur cette réponse (et histoire de pas être totalement hors charte et me faire honteusement rejeter par les gentils modérateurs), le md5 a été étudié, décortiqué, retourné dans tous les sens et personne n'a jamais trouvé de failles. Je crois que Bruce Schneier parlait d'une "légère asymétrie" dans les tables, mais en gros rien d'exploitable même théoriquement.
Aucune collision n'a jamais été trouvée, ce qui est normal si on considère qu'il faudrait en moyenne 2^(128/2) éléments md5-isés pour en trouver une, et considérant que 2^64 c'est tout de même "vachement grand pour le moment". (Une itération simple de 0 -> 2^64 est pour le moment inaccessible, même en cumulant la puissance de calcul mondiale)
Jacques Caron wrote:
C'est un peu
comme dire que tu connais les horaires des trains mais tu ne sais pas à
quelle heure ils partent...
Euh avec la SNCF, on connait les horaires de trains mais on ne sait jamais
quand ils partent. Bon, ok, je sort.
Pour rebondir sur cette réponse (et histoire de pas être totalement hors
charte et me faire honteusement rejeter par les gentils modérateurs), le
md5 a été étudié, décortiqué, retourné dans tous les sens et personne n'a
jamais trouvé de failles. Je crois que Bruce Schneier parlait d'une "légère
asymétrie" dans les tables, mais en gros rien d'exploitable même théoriquement.
Aucune collision n'a jamais été trouvée, ce qui est normal si on considère
qu'il faudrait en moyenne 2^(128/2) éléments md5-isés pour en trouver une,
et considérant que 2^64 c'est tout de même "vachement grand pour le moment".
(Une itération simple de 0 -> 2^64 est pour le moment inaccessible, même en
cumulant la puissance de calcul mondiale)
C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Euh avec la SNCF, on connait les horaires de trains mais on ne sait jamais quand ils partent. Bon, ok, je sort.
Pour rebondir sur cette réponse (et histoire de pas être totalement hors charte et me faire honteusement rejeter par les gentils modérateurs), le md5 a été étudié, décortiqué, retourné dans tous les sens et personne n'a jamais trouvé de failles. Je crois que Bruce Schneier parlait d'une "légère asymétrie" dans les tables, mais en gros rien d'exploitable même théoriquement.
Aucune collision n'a jamais été trouvée, ce qui est normal si on considère qu'il faudrait en moyenne 2^(128/2) éléments md5-isés pour en trouver une, et considérant que 2^64 c'est tout de même "vachement grand pour le moment". (Une itération simple de 0 -> 2^64 est pour le moment inaccessible, même en cumulant la puissance de calcul mondiale)
Eric CHAPUZOT
Pour tester en ligne: <http://www.bibmath.net/crypto/moderne/md5.php3>
enfin, pour l'inclure dans un programme, j'ai trouvé bien mieux :
http://www.fichtner.net/delphi/md5.delphi.phtml
ca marche impeccablement bien... ... par contre, remonter le courant du flux md5, ca relève très franchement du rat dans son labyrinthe avec la nuance près que ce n'est qu'après avoir remonté les 256 niveaux de colin-mayard qu'on peut s'assurer de ne pas avoir emprunté une impasse... et à chaque niveau, il peut y avoir presque la totalité en possibilités , soit un Dword $FFFF FFFF les opérations étant généralement triple-booléennes....
mais il parait que les petits rats arrivent à s'organiser pour sortir de la plupart des labyrinthes... en fait ca se résume à une opération 64 bits $80000000 00000000-00000000 00000000-00000000 00000000-00000000 00000000 (X) blockMd5(64 bytes) ->$FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF
pour arranger la sauce, qui s'enchaine plusieurs fois...
Pour tester en ligne:
<http://www.bibmath.net/crypto/moderne/md5.php3>
enfin, pour l'inclure dans un programme, j'ai trouvé bien mieux :
http://www.fichtner.net/delphi/md5.delphi.phtml
ca marche impeccablement bien...
... par contre, remonter le courant du flux md5, ca relève très franchement
du rat dans son labyrinthe avec la nuance près que ce n'est qu'après avoir
remonté les 256 niveaux de colin-mayard qu'on peut s'assurer de ne pas avoir
emprunté une impasse...
et à chaque niveau, il peut y avoir presque la totalité en possibilités ,
soit un Dword $FFFF FFFF
les opérations étant généralement triple-booléennes....
mais il parait que les petits rats arrivent à s'organiser pour sortir de la
plupart des labyrinthes...
en fait ca se résume à une opération 64 bits
$80000000 00000000-00000000 00000000-00000000 00000000-00000000 00000000
(X) blockMd5(64 bytes)
->$FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF
pour arranger la sauce, qui s'enchaine plusieurs fois...
Pour tester en ligne: <http://www.bibmath.net/crypto/moderne/md5.php3>
enfin, pour l'inclure dans un programme, j'ai trouvé bien mieux :
http://www.fichtner.net/delphi/md5.delphi.phtml
ca marche impeccablement bien... ... par contre, remonter le courant du flux md5, ca relève très franchement du rat dans son labyrinthe avec la nuance près que ce n'est qu'après avoir remonté les 256 niveaux de colin-mayard qu'on peut s'assurer de ne pas avoir emprunté une impasse... et à chaque niveau, il peut y avoir presque la totalité en possibilités , soit un Dword $FFFF FFFF les opérations étant généralement triple-booléennes....
mais il parait que les petits rats arrivent à s'organiser pour sortir de la plupart des labyrinthes... en fait ca se résume à une opération 64 bits $80000000 00000000-00000000 00000000-00000000 00000000-00000000 00000000 (X) blockMd5(64 bytes) ->$FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF-FFFFFFFF FFFFFFFF
pour arranger la sauce, qui s'enchaine plusieurs fois...
Fabien LE LEZ
On 17 May 2004 23:41:25 GMT, "Eric CHAPUZOT" wrote:
ha, c'est que ca, j'ai presqu'envie de parier que je n'en ai que pour une demie-heure en langage-machine sur mon ordi 1700Mhz...
Y'a une solution : tu mesures le temps de calcul de 1 hash MD5 avec une implémentation en C (facile à trouver), tu multiplies par 2^128, tu divises par un facteur d'optimisation (tu peux le choisir entre 2 et 10^6) si tu penses qu'en langage machine ça ira plus vite, et tu obtiens le temps de calcul total.
Autre solution : tu considères que tu es assez doué pour calculer un MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 200166098188787331449043886724 secondes (soit 6343011143433222937660 années environ).
Tu écrivais par ailleurs :
si je considère l'ensemble de tous les fichiers qui font 17 octets
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42 octets. Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse 500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26 tonnes, soit environ cent mille fois plus que la Terre -- ou encore, environ le tiers de la masse du soleil.
-- ;-) FLL, Epagneul Breton
On 17 May 2004 23:41:25 GMT, "Eric CHAPUZOT" <echap@evhr.net> wrote:
ha, c'est que ca, j'ai presqu'envie de parier que je n'en ai que pour une
demie-heure en langage-machine sur mon ordi 1700Mhz...
Y'a une solution : tu mesures le temps de calcul de 1 hash MD5 avec
une implémentation en C (facile à trouver), tu multiplies par 2^128,
tu divises par un facteur d'optimisation (tu peux le choisir entre 2
et 10^6) si tu penses qu'en langage machine ça ira plus vite, et tu
obtiens le temps de calcul total.
Autre solution : tu considères que tu es assez doué pour calculer un
MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par
seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 200166098188787331449043886724 secondes (soit 6343011143433222937660
années environ).
Tu écrivais par ailleurs :
si je considère l'ensemble de tous les fichiers qui font 17 octets
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en
a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42
octets.
Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse
500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26
tonnes, soit environ cent mille fois plus que la Terre -- ou encore,
environ le tiers de la masse du soleil.
On 17 May 2004 23:41:25 GMT, "Eric CHAPUZOT" wrote:
ha, c'est que ca, j'ai presqu'envie de parier que je n'en ai que pour une demie-heure en langage-machine sur mon ordi 1700Mhz...
Y'a une solution : tu mesures le temps de calcul de 1 hash MD5 avec une implémentation en C (facile à trouver), tu multiplies par 2^128, tu divises par un facteur d'optimisation (tu peux le choisir entre 2 et 10^6) si tu penses qu'en langage machine ça ira plus vite, et tu obtiens le temps de calcul total.
Autre solution : tu considères que tu es assez doué pour calculer un MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 200166098188787331449043886724 secondes (soit 6343011143433222937660 années environ).
Tu écrivais par ailleurs :
si je considère l'ensemble de tous les fichiers qui font 17 octets
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42 octets. Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse 500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26 tonnes, soit environ cent mille fois plus que la Terre -- ou encore, environ le tiers de la masse du soleil.
-- ;-) FLL, Epagneul Breton
Eric CHAPUZOT
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Jacques. Comme dit ailleurs, y a 24 heures, je ne connaissais quasiment rien du md5
et des gens très intelligents s'y sont cassé le nez tout au long de ces 10 dernières années au moins... j'ai sûrement encore moins de chance que de gagner au loto.
enfin ptêt quand même qu'en applicant quelques concepts d'automatisme sur les tableaux de carnaugh et/ou les variables ré-entrantes, on peut toujours espérer... avec de la persévérence ou un ordi pas trop con, on doit pouvoir tirer la loi booléenne pour chaque octet du code... Octet1=$00.(abcd=X0+Y0+Z0+T0...) +$01.... +$FF..... .... Octet16=.... puis considérer les intersections....
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme
dire que tu connais les horaires des trains mais tu ne sais pas à quelle
heure ils partent...
Jacques.
Comme dit ailleurs, y a 24 heures, je ne connaissais quasiment rien du md5
et des gens très intelligents s'y sont cassé le nez tout au long de ces 10
dernières années au moins... j'ai sûrement encore moins de chance que de
gagner au loto.
enfin ptêt quand même qu'en applicant quelques concepts d'automatisme sur
les tableaux de carnaugh et/ou les variables ré-entrantes, on peut toujours
espérer...
avec de la persévérence ou un ordi pas trop con, on doit pouvoir tirer la
loi booléenne pour chaque octet du code...
Octet1=$00.(abcd=X0+Y0+Z0+T0...)
+$01....
+$FF.....
....
Octet16=....
puis considérer les intersections....
C'est intéressant comme concept, ce que tu nous dis là. C'est un peu comme dire que tu connais les horaires des trains mais tu ne sais pas à quelle heure ils partent...
Jacques. Comme dit ailleurs, y a 24 heures, je ne connaissais quasiment rien du md5
et des gens très intelligents s'y sont cassé le nez tout au long de ces 10 dernières années au moins... j'ai sûrement encore moins de chance que de gagner au loto.
enfin ptêt quand même qu'en applicant quelques concepts d'automatisme sur les tableaux de carnaugh et/ou les variables ré-entrantes, on peut toujours espérer... avec de la persévérence ou un ordi pas trop con, on doit pouvoir tirer la loi booléenne pour chaque octet du code... Octet1=$00.(abcd=X0+Y0+Z0+T0...) +$01.... +$FF..... .... Octet16=.... puis considérer les intersections....
Alain Montfranc
Eric CHAPUZOT wrote:
"Guillermito" a écrit dans le message de
Le hic, c'est que vous ne comprenez pas que 2^128, c'est *vraiment* très beaucoup beaucoup beaucoup, et que la vitesse d'implémentation est un facteur peu important devant l'immensité cosmogonique de l'espace des hashs.
le hic, c'est que même mathématiquement, c'est même pas rigolo comme truc, il suffit de souffler dessus pour toutes tes trop belles théories s'envolent...
rien que si je considère l'ensemble de tous les fichiers qui font 17 octets, j'en trouverais 16^15 ayant même empreinte, même crc... et 16^15, ca fait, beaucoup,beaucoup de failles, si tu me comprends...
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
"Guillermito" <guillermito@pipo.com> a écrit dans le message de
Le hic, c'est que vous ne comprenez pas que 2^128, c'est *vraiment* très
beaucoup beaucoup beaucoup, et que la vitesse d'implémentation est un
facteur peu important devant l'immensité cosmogonique de l'espace des
hashs.
le hic, c'est que même mathématiquement, c'est même pas rigolo comme truc,
il suffit de souffler dessus pour toutes tes trop belles théories
s'envolent...
rien que si je considère l'ensemble de tous les fichiers qui font 17 octets,
j'en trouverais 16^15 ayant même empreinte, même crc... et 16^15, ca fait,
beaucoup,beaucoup de failles, si tu me comprends...
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs
possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous
n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
Le hic, c'est que vous ne comprenez pas que 2^128, c'est *vraiment* très beaucoup beaucoup beaucoup, et que la vitesse d'implémentation est un facteur peu important devant l'immensité cosmogonique de l'espace des hashs.
le hic, c'est que même mathématiquement, c'est même pas rigolo comme truc, il suffit de souffler dessus pour toutes tes trop belles théories s'envolent...
rien que si je considère l'ensemble de tous les fichiers qui font 17 octets, j'en trouverais 16^15 ayant même empreinte, même crc... et 16^15, ca fait, beaucoup,beaucoup de failles, si tu me comprends...
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
On 18 May 2004 21:10:46 GMT, Alain Montfranc wrote:
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5.
AMHA, si. Plus exactement, on n'est pas sûr que les 2^128 valeurs seront atteintes, mais étant donné qu'on a une redondance importante (256 fois trop de valeurs) et que l'encodage MD5 est a priori quasiment sans biais (sinon sa force serait amoindrie), la probabilité que l'application ne soit pas surjective est quand même très faible, peut-être même inférieure à la probabilité de trouver une collision au premier essai.
-- ;-) FLL, Epagneul Breton
On 18 May 2004 21:10:46 GMT, Alain Montfranc
<alain-news@montfranc.com> wrote:
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs
possibles des clefs MD5.
AMHA, si.
Plus exactement, on n'est pas sûr que les 2^128 valeurs seront
atteintes, mais étant donné qu'on a une redondance importante (256
fois trop de valeurs) et que l'encodage MD5 est a priori quasiment
sans biais (sinon sa force serait amoindrie), la probabilité que
l'application ne soit pas surjective est quand même très faible,
peut-être même inférieure à la probabilité de trouver une collision au
premier essai.
On 18 May 2004 21:10:46 GMT, Alain Montfranc wrote:
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5.
AMHA, si. Plus exactement, on n'est pas sûr que les 2^128 valeurs seront atteintes, mais étant donné qu'on a une redondance importante (256 fois trop de valeurs) et que l'encodage MD5 est a priori quasiment sans biais (sinon sa force serait amoindrie), la probabilité que l'application ne soit pas surjective est quand même très faible, peut-être même inférieure à la probabilité de trouver une collision au premier essai.
-- ;-) FLL, Epagneul Breton
Etienne de Tocqueville
Fabien LE LEZ a écrit sur fr.comp.securite :
Autre solution : tu considères que tu es assez doué pour calculer un MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 > 200166098188787331449043886724 secondes (soit 6343011143433222937660 années environ).
Oui mais si on considère que dans 10 ans, on aura des machines 1 milliard de fois plus puissantes, et si on considère que l'on peut disposer simultanément de 1 petit million de ces machines, alors il ne faudra que 6343011 années. Tu vois que ça devient raisonnable !
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42 octets. Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse 500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26 tonnes, soit environ cent mille fois plus que la Terre -- ou encore, environ le tiers de la masse du soleil.
La solution est donc toute trouvée : il suffit de savoir comment graver les fichiers dans le soleil !
Fabien LE LEZ <gramster@gramster.com> a écrit sur fr.comp.securite :
Autre solution : tu considères que tu es assez doué pour calculer un
MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par
seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 > 200166098188787331449043886724 secondes (soit 6343011143433222937660
années environ).
Oui mais si on considère que dans 10 ans, on aura des machines 1
milliard de fois plus puissantes, et si on considère que l'on peut
disposer simultanément de 1 petit million de ces machines, alors il ne
faudra que 6343011 années. Tu vois que ça devient raisonnable !
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en
a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42
octets.
Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse
500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26
tonnes, soit environ cent mille fois plus que la Terre -- ou encore,
environ le tiers de la masse du soleil.
La solution est donc toute trouvée : il suffit de savoir comment graver
les fichiers dans le soleil !
Autre solution : tu considères que tu es assez doué pour calculer un MD5 en un seul cycle processeur. Il y a 1700 millions de cycles par seconde, donc 2^128 calculs ne devraient durer que 2^128/1,7.10^9 > 200166098188787331449043886724 secondes (soit 6343011143433222937660 années environ).
Oui mais si on considère que dans 10 ans, on aura des machines 1 milliard de fois plus puissantes, et si on considère que l'on peut disposer simultanément de 1 petit million de ces machines, alors il ne faudra que 6343011 années. Tu vois que ça devient raisonnable !
Tu risques d'avoir un peu de mal à les stocker, ces fichiers : il y en a 256^17 = 8,7.10^40. Ce qui donne une taille totale de 1,48.10^42 octets. Ça n'a l'air de rien, comme ça, mais si un disque dur de 1 To pèse 500g, les 1,48.10^30 disques durs nécessaires pèseront 7,4.10^26 tonnes, soit environ cent mille fois plus que la Terre -- ou encore, environ le tiers de la masse du soleil.
La solution est donc toute trouvée : il suffit de savoir comment graver les fichiers dans le soleil !
Eric CHAPUZOT
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
bijection, injection, surjection, souvenirs, souvenirs ;-) c'est vrai, c'est injectif mais pas forcément surjectif...
du coup, une clef md5 sur 17 octets peut ne correspondre qu'à un seul code-source mais pour ce faire, il faut qu'ailleurs, une autre clef entre à chaque fois en collision une fois de plus... du coup, le nombre de collisions restera quand même le même...
moi, ce qui me complique la tâche surtout en inversant une clef md5, c'est que je voudrais des caractères de message tous ascii et ca fait chercher loin sur des horizons, sinon une inversion en octets purs serait presqu'immédiate, en prenant à chaque fois le premier embranchement qui se présente sur les opérations ternaires... d'ailleurs même ca, c'est pas trop facile à mettre en oeuvre... pour l'instant, je n'ai fait le code que pour inverser la premiere branche du bouton II, restent HH,GG et FF puis faire en sorte d'explorer quand même un petit paquet de branches inversées pour en trouver une un peu convenable...
le rêve serait de rentrer évidemment par les deux bouts et faire que ca coincide au milieu , pour que n'importe quel message puisse atteindre une clef md5 donnée en y adjoignant juste quelques caractères en plus. genre : mon message : ca marche ? clef visée: 5ad4f7044b385918f3b7276ced0cd61f réponse de l'ordinateur: vous devez taper : ca marche ? 4cc14acf6892314ae53aecd59aae04f3
là on prouverait si on garde 5 fois la même clef de collision qu'on a inversé le md5
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs
possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous
n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
bijection, injection, surjection, souvenirs, souvenirs ;-)
c'est vrai, c'est injectif mais pas forcément surjectif...
du coup, une clef md5 sur 17 octets peut ne correspondre qu'à un seul
code-source
mais pour ce faire, il faut qu'ailleurs, une autre clef entre à chaque fois
en collision une fois de plus...
du coup, le nombre de collisions restera quand même le même...
moi, ce qui me complique la tâche surtout en inversant une clef md5, c'est
que je voudrais des caractères de message tous ascii et ca fait chercher
loin sur des horizons, sinon une inversion en octets purs serait
presqu'immédiate, en prenant à chaque fois le premier embranchement qui se
présente sur les opérations ternaires...
d'ailleurs même ca, c'est pas trop facile à mettre en oeuvre... pour
l'instant, je n'ai fait le code que pour inverser la premiere branche du
bouton II, restent HH,GG et FF puis faire en sorte d'explorer quand même un
petit paquet de branches inversées pour en trouver une un peu convenable...
le rêve serait de rentrer évidemment par les deux bouts et faire que ca
coincide au milieu , pour que n'importe quel message puisse atteindre une
clef md5 donnée en y adjoignant juste quelques caractères en plus.
genre :
mon message : ca marche ?
clef visée: 5ad4f7044b385918f3b7276ced0cd61f
réponse de l'ordinateur: vous devez taper : ca marche ?
4cc14acf6892314ae53aecd59aae04f3
là on prouverait si on garde 5 fois la même clef de collision qu'on a
inversé le md5
vos fichiers de 17 octets ne couvrirons pas l'ensemble des valeurs possibles des clefs MD5. Il y aura des collisions c'est sur, mais vous n'etes pas certain de trouver 1 seul fichier pour une signature MD5 donnée
bijection, injection, surjection, souvenirs, souvenirs ;-) c'est vrai, c'est injectif mais pas forcément surjectif...
du coup, une clef md5 sur 17 octets peut ne correspondre qu'à un seul code-source mais pour ce faire, il faut qu'ailleurs, une autre clef entre à chaque fois en collision une fois de plus... du coup, le nombre de collisions restera quand même le même...
moi, ce qui me complique la tâche surtout en inversant une clef md5, c'est que je voudrais des caractères de message tous ascii et ca fait chercher loin sur des horizons, sinon une inversion en octets purs serait presqu'immédiate, en prenant à chaque fois le premier embranchement qui se présente sur les opérations ternaires... d'ailleurs même ca, c'est pas trop facile à mettre en oeuvre... pour l'instant, je n'ai fait le code que pour inverser la premiere branche du bouton II, restent HH,GG et FF puis faire en sorte d'explorer quand même un petit paquet de branches inversées pour en trouver une un peu convenable...
le rêve serait de rentrer évidemment par les deux bouts et faire que ca coincide au milieu , pour que n'importe quel message puisse atteindre une clef md5 donnée en y adjoignant juste quelques caractères en plus. genre : mon message : ca marche ? clef visée: 5ad4f7044b385918f3b7276ced0cd61f réponse de l'ordinateur: vous devez taper : ca marche ? 4cc14acf6892314ae53aecd59aae04f3
là on prouverait si on garde 5 fois la même clef de collision qu'on a inversé le md5
Erwann ABALEA
On Wed, 19 May 2004, Erwann ABALEA wrote:
On 18 May 2004, Eric CHAPUZOT wrote:
[...]
Si tu sais évaluer tes chances de gagner au loto (on va simplifier, on ne va parler que de statistiques, pas de probabilités), tu sais alors évaluer la 'facilité' de gagner au loto par rapport à la 'difficulté' de casser MD5.
J'oubliais: avant d'apporter ta contribution au réchauffement de la planète en poussant ton 1.7 GHz, tu devrais sérieusement lire un peu de la littérature consacrée et réfléchir avant: - d'agir, - de causer. Il y a de très bons bouquins, autant pour ceux qui aiment les histoires ("The Codebreakers" de David Kahn par exemple) que ceux qui préfèrent la technique (Le célèbre "Applied Cryptography" de Schneier, le très didactique "Cryptographie, théorie et pratique" de Douglas Stinson traduit par Serge Vaudenay, ou le très complet et précis "Handbook of Applied Cryptography" qu'on trouve intégralement, gratuitement et légalement sur le web).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Pour le record de neuneuterie, comme tu vois, nous sommes plusieurs sur le coup. Quand je pense qu'il y en a qui font la gueule d'être dans le gnu, alors que moi, je fais tout ce que je peux pour y figurer ! -+- PB in GNU : ne me remerciez pas, j'aime à rendre service.
On Wed, 19 May 2004, Erwann ABALEA wrote:
On 18 May 2004, Eric CHAPUZOT wrote:
[...]
Si tu sais évaluer tes chances de gagner au loto (on va simplifier, on ne
va parler que de statistiques, pas de probabilités), tu sais alors évaluer
la 'facilité' de gagner au loto par rapport à la 'difficulté' de casser
MD5.
J'oubliais: avant d'apporter ta contribution au réchauffement de la
planète en poussant ton 1.7 GHz, tu devrais sérieusement lire un peu de la
littérature consacrée et réfléchir avant:
- d'agir,
- de causer.
Il y a de très bons bouquins, autant pour ceux qui aiment les histoires
("The Codebreakers" de David Kahn par exemple) que ceux qui préfèrent la
technique (Le célèbre "Applied Cryptography" de Schneier, le très
didactique "Cryptographie, théorie et pratique" de Douglas Stinson traduit
par Serge Vaudenay, ou le très complet et précis "Handbook of Applied
Cryptography" qu'on trouve intégralement, gratuitement et légalement sur
le web).
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Pour le record de neuneuterie, comme tu vois, nous sommes plusieurs sur
le coup. Quand je pense qu'il y en a qui font la gueule d'être dans le
gnu, alors que moi, je fais tout ce que je peux pour y figurer !
-+- PB in GNU : ne me remerciez pas, j'aime à rendre service.
Si tu sais évaluer tes chances de gagner au loto (on va simplifier, on ne va parler que de statistiques, pas de probabilités), tu sais alors évaluer la 'facilité' de gagner au loto par rapport à la 'difficulté' de casser MD5.
J'oubliais: avant d'apporter ta contribution au réchauffement de la planète en poussant ton 1.7 GHz, tu devrais sérieusement lire un peu de la littérature consacrée et réfléchir avant: - d'agir, - de causer. Il y a de très bons bouquins, autant pour ceux qui aiment les histoires ("The Codebreakers" de David Kahn par exemple) que ceux qui préfèrent la technique (Le célèbre "Applied Cryptography" de Schneier, le très didactique "Cryptographie, théorie et pratique" de Douglas Stinson traduit par Serge Vaudenay, ou le très complet et précis "Handbook of Applied Cryptography" qu'on trouve intégralement, gratuitement et légalement sur le web).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Pour le record de neuneuterie, comme tu vois, nous sommes plusieurs sur le coup. Quand je pense qu'il y en a qui font la gueule d'être dans le gnu, alors que moi, je fais tout ce que je peux pour y figurer ! -+- PB in GNU : ne me remerciez pas, j'aime à rendre service.
