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?
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... enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse... enfin, c'est même pas vraiment un hic, puisque grosso modo on peut faire que ca n'intervienne qu'une seule fois dans une stratégie glissante... 2 Ghz, ca veut quand même dire un débit de presque 16e8 instructions à la seconde (déjà la moitié du travail) et avec des stratégies de oerth, tout n'est de loin pas à calculer dans ce que tu dis à fort juste titre être un espace fini...
il y a même des infinités de fichiers qui ont la même signature... je suis certain que ca doit intéresser fortement l'industrie cinématographique...
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... enfin, le hic c'est
que je ne connais pas l'algo md5 et sa rapidité de réponse... enfin, c'est
même pas vraiment un hic, puisque grosso modo on peut faire que ca
n'intervienne qu'une seule fois dans une stratégie glissante... 2 Ghz, ca
veut quand même dire un débit de presque 16e8 instructions à la seconde
(déjà la moitié du travail) et avec des stratégies de oerth, tout n'est de
loin pas à calculer dans ce que tu dis à fort juste titre être un espace
fini...
il y a même des infinités de fichiers qui ont la même signature... je suis
certain que ca doit intéresser fortement l'industrie cinématographique...
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... enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse... enfin, c'est même pas vraiment un hic, puisque grosso modo on peut faire que ca n'intervienne qu'une seule fois dans une stratégie glissante... 2 Ghz, ca veut quand même dire un débit de presque 16e8 instructions à la seconde (déjà la moitié du travail) et avec des stratégies de oerth, tout n'est de loin pas à calculer dans ce que tu dis à fort juste titre être un espace fini...
il y a même des infinités de fichiers qui ont la même signature... je suis certain que ca doit intéresser fortement l'industrie cinématographique...
Guillermito
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...
Je vous ai déjà expliqué, avec des chiffres, que votre intuition vous a trompé d'un facteur 100000000000000000000000000000 dans un message précédent.
enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse...
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.
Je vous invite à lire la FAQ de Thomas Pornin, sur la taille des clefs de cryptographie, mais on peut étendre certaines observations à propos des hashs, marrante à lire et très instructive:
http://www.ifrance.com/maliks/faq-cle.html
-- Guillermito http://www.guillermito2.net
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...
Je vous ai déjà expliqué, avec des chiffres, que votre intuition vous a
trompé d'un facteur 100000000000000000000000000000 dans un message
précédent.
enfin, le hic c'est
que je ne connais pas l'algo md5 et sa rapidité de réponse...
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.
Je vous invite à lire la FAQ de Thomas Pornin, sur la taille des clefs
de cryptographie, mais on peut étendre certaines observations à propos
des hashs, marrante à lire et très instructive:
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...
Je vous ai déjà expliqué, avec des chiffres, que votre intuition vous a trompé d'un facteur 100000000000000000000000000000 dans un message précédent.
enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse...
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.
Je vous invite à lire la FAQ de Thomas Pornin, sur la taille des clefs de cryptographie, mais on peut étendre certaines observations à propos des hashs, marrante à lire et très instructive:
http://www.ifrance.com/maliks/faq-cle.html
-- Guillermito http://www.guillermito2.net
Eric CHAPUZOT
"Cedric Blancher" a écrit dans le message de news:
- trouver deux fichiers qui ont la même empreinte. ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte [...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien
à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de départ est infini (l'ensemble des messages) alors que l'espace d'arrivée est fini (ensemble de mots de 128 bits). Les collisions sont donc possibles.
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de
social-enginiering... ... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Ce type de recherche ne semble pas possible en dehors de la recherche exhaustive, ce qui nous amène à un problème grosso modo équivalent à casser un clé de 128 bits en force brute, ce que des gens nettement plus compétents que moi sur fr.misc.cryptologie considèrent au delà des moyens technologiques (connus) disponibles aujourd'hui.
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16 octets parce que je t'en aurais voulu de trouver un grand nombre de solution sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je verrais un jour où je suis bien luné...
évidemment, c'est pas vraiment du craquage de force brute comme tu aurais pu en rêver... ca, on peut encore le mettre dans la partie rêves. Mais bon, je peux encore écrire 10e137 sans que l'ordi ne fasse une boucle réelle jusque là...
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news:pan.2004.05.17.20.34.46.57183@cartel-securite.fr...
- trouver deux fichiers qui ont la même empreinte.
ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte
[...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure
rien
à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de
départ est infini (l'ensemble des messages) alors que l'espace d'arrivée
est fini (ensemble de mots de 128 bits). Les collisions sont donc
possibles.
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de
social-enginiering...
... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Ce
type de recherche ne semble pas possible en dehors de la recherche
exhaustive, ce qui nous amène à un problème grosso modo équivalent à
casser un clé de 128 bits en force brute, ce que des gens nettement plus
compétents que moi sur fr.misc.cryptologie considèrent au delà des
moyens technologiques (connus) disponibles aujourd'hui.
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16
octets parce que je t'en aurais voulu de trouver un grand nombre de solution
sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt
qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je
verrais un jour où je suis bien luné...
évidemment, c'est pas vraiment du craquage de force brute comme tu aurais pu
en rêver... ca, on peut encore le mettre dans la partie rêves. Mais bon, je
peux encore écrire 10e137 sans que l'ordi ne fasse une boucle réelle jusque
là...
"Cedric Blancher" a écrit dans le message de news:
- trouver deux fichiers qui ont la même empreinte. ca me parait hautement improbable avec 16 octets qu'on ne tombe pas
plusieurs fois sur des fichiers différents mais ayant la même empreinte [...]
donc tout au plus, ca réduit le champ d'investigation mais ca n'assure rien
à grande échelle...
Tu as absolument raison. C'est complètement mathématique. L'espace de départ est infini (l'ensemble des messages) alors que l'espace d'arrivée est fini (ensemble de mots de 128 bits). Les collisions sont donc possibles.
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de
social-enginiering... ... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Ce type de recherche ne semble pas possible en dehors de la recherche exhaustive, ce qui nous amène à un problème grosso modo équivalent à casser un clé de 128 bits en force brute, ce que des gens nettement plus compétents que moi sur fr.misc.cryptologie considèrent au delà des moyens technologiques (connus) disponibles aujourd'hui.
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16 octets parce que je t'en aurais voulu de trouver un grand nombre de solution sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je verrais un jour où je suis bien luné...
évidemment, c'est pas vraiment du craquage de force brute comme tu aurais pu en rêver... ca, on peut encore le mettre dans la partie rêves. Mais bon, je peux encore écrire 10e137 sans que l'ordi ne fasse une boucle réelle jusque là...
Eric CHAPUZOT
"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...
"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...
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...
Cedric Blancher
Le Tue, 18 May 2004 07:31:21 +0000, Eric CHAPUZOT a écrit :
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de social-enginiering... ... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Pas compris là, mais bon...
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16 octets parce que je t'en aurais voulu de trouver un grand nombre de solution sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je verrais un jour où je suis bien luné...
Ben lune toi bien, et _FAIS_ le au lieu de supposer que en langage en machine blablabla ça ira vite. Dès que tu auras trouvé deux passwords qui donne le même hash que celui que je t'ai donné, tu me fais signe. Mais s'il te plaît, dans l'intervalle, arrête de raconter des conneries.
--
COIN ! Comment ça coin ?
Juste melangé 8.5 et X je suppose... -+- In : Guide du Neueu Usenet - Le canard se déchaine -+-
Le Tue, 18 May 2004 07:31:21 +0000, Eric CHAPUZOT a écrit :
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de
social-enginiering...
... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Pas compris là, mais bon...
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16
octets parce que je t'en aurais voulu de trouver un grand nombre de solution
sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt
qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je
verrais un jour où je suis bien luné...
Ben lune toi bien, et _FAIS_ le au lieu de supposer que en langage en
machine blablabla ça ira vite. Dès que tu auras trouvé deux passwords
qui donne le même hash que celui que je t'ai donné, tu me fais signe.
Mais s'il te plaît, dans l'intervalle, arrête de raconter des conneries.
--
COIN !
Comment ça coin ?
Juste melangé 8.5 et X je suppose...
-+- In : Guide du Neueu Usenet - Le canard se déchaine -+-
Le Tue, 18 May 2004 07:31:21 +0000, Eric CHAPUZOT a écrit :
Ca fait plaisir à entendre mais t'as encore fait un paquet immense de social-enginiering... ... bon, t'es très fort, sans ton aide, jamais, jamais je n'y serais arrivé.
Pas compris là, mais bon...
par contre, ca, heureusement que j'ai pas trop cherché dans ton paquet de 16 octets parce que je t'en aurais voulu de trouver un grand nombre de solution sans même pouvoir faire d'hypothèses sérieuses sur la bonne... enfin, ptêt qu'il y en aurait eu beaucoup moins ne contenant que des lettres... je verrais un jour où je suis bien luné...
Ben lune toi bien, et _FAIS_ le au lieu de supposer que en langage en machine blablabla ça ira vite. Dès que tu auras trouvé deux passwords qui donne le même hash que celui que je t'ai donné, tu me fais signe. Mais s'il te plaît, dans l'intervalle, arrête de raconter des conneries.
--
COIN ! Comment ça coin ?
Juste melangé 8.5 et X je suppose... -+- In : Guide du Neueu Usenet - Le canard se déchaine -+-
Thierry
Bonjour,
Eric CHAPUZOT a écrit :
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... enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse...
http://rfc.sunsite.dk/rfc/rfc1321.html Plus aucune excuse pour essayer.
-- « Always look at the bright side of the life... »
Bonjour,
Eric CHAPUZOT a écrit :
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... enfin, le
hic c'est que je ne connais pas l'algo md5 et sa rapidité de
réponse...
http://rfc.sunsite.dk/rfc/rfc1321.html
Plus aucune excuse pour essayer.
--
« Always look at the bright side of the life... »
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... enfin, le hic c'est que je ne connais pas l'algo md5 et sa rapidité de réponse...
http://rfc.sunsite.dk/rfc/rfc1321.html Plus aucune excuse pour essayer.
-- « Always look at the bright side of the life... »
T0t0
"Eric CHAPUZOT" wrote in message news:40a9b24d$0$24308$
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...
Mouarf, à première vue, je dirais qu'il faudrait que tu essayes de comprendre les principes que Cédric et Guillermito essayent vainement de te faire comprendre en abordant pourtant le sujet en langage simple. Et après, tu comprendras peut-être par la même occasion le non-sens que tu essayes de nous faire passer comme une vérité qui serait passée sous le nez des cryptologues depuis des années...
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...
Oui, du moins j'en ai l'impression. Mais peut-être qu'un exemple serait plus parlant. Je prends le texte suivant: "Cher Neric,
Il fait si froid à Dniepopetrovsk... [...] ... Très sincèrement,
T0t0"
Les [...] exprimant la suite du texte que j'ai la flemme de taper. J'en fais un hash MD5 que j'envoies au destinataire par une autre voie sécurisée. Disons que tu interceptes la communication et que tu souhaites m'envoyer un faux message. Il te faut donc créer un autre message _intelligible_ qui ait le même hash MD5. Comme tu l'as écrit, il y en a une foultitude. Par contre, la probabilité que parmis cette foultitude il y en ait un seul qui soit intelligible et qui contienne du texte intéressant pour toi est tout simplement quasiment nulle. Ou du moins, la puissance de calcul nécessaire pour le calculer est gigantesque, si jamais la collision correcte existe. Donc, il t'es impossible de falsifier un message dont le destinataire possède le hash MD5. Même si des collisions existent, comme tu le soulignes. Il est fort improbable que ces collisions aient un sens dans le langage utilisé à l'origine (ascii, binaire, ou autre) C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas facile de trouver des collisions, mais les chances que ces collisions soient exploitables sont nulles...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Eric CHAPUZOT" <echap@evhr.net> wrote in message
news:40a9b24d$0$24308$4d4eb98e@read.news.fr.uu.net
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...
Mouarf, à première vue, je dirais qu'il faudrait que tu essayes de
comprendre les principes que Cédric et Guillermito essayent vainement
de te faire comprendre en abordant pourtant le sujet en langage simple.
Et après, tu comprendras peut-être par la même occasion le non-sens que
tu essayes de nous faire passer comme une vérité qui serait passée
sous le nez des cryptologues depuis des années...
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...
Oui, du moins j'en ai l'impression. Mais peut-être qu'un exemple
serait plus parlant.
Je prends le texte suivant:
"Cher Neric,
Il fait si froid à Dniepopetrovsk...
[...]
... Très sincèrement,
T0t0"
Les [...] exprimant la suite du texte que j'ai la flemme de taper.
J'en fais un hash MD5 que j'envoies au destinataire par une autre voie
sécurisée.
Disons que tu interceptes la communication et que tu souhaites
m'envoyer un faux message. Il te faut donc créer un autre message
_intelligible_ qui ait le même hash MD5.
Comme tu l'as écrit, il y en a une foultitude. Par contre, la
probabilité que parmis cette foultitude il y en ait un seul qui
soit intelligible et qui contienne du texte intéressant pour toi est
tout simplement quasiment nulle. Ou du moins, la puissance de calcul
nécessaire pour le calculer est gigantesque, si jamais la collision
correcte existe.
Donc, il t'es impossible de falsifier un message dont le destinataire
possède le hash MD5.
Même si des collisions existent, comme tu le soulignes. Il est
fort improbable que ces collisions aient un sens dans le langage
utilisé à l'origine (ascii, binaire, ou autre)
C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas
facile de trouver des collisions, mais les chances que ces
collisions soient exploitables sont nulles...
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Eric CHAPUZOT" wrote in message news:40a9b24d$0$24308$
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...
Mouarf, à première vue, je dirais qu'il faudrait que tu essayes de comprendre les principes que Cédric et Guillermito essayent vainement de te faire comprendre en abordant pourtant le sujet en langage simple. Et après, tu comprendras peut-être par la même occasion le non-sens que tu essayes de nous faire passer comme une vérité qui serait passée sous le nez des cryptologues depuis des années...
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...
Oui, du moins j'en ai l'impression. Mais peut-être qu'un exemple serait plus parlant. Je prends le texte suivant: "Cher Neric,
Il fait si froid à Dniepopetrovsk... [...] ... Très sincèrement,
T0t0"
Les [...] exprimant la suite du texte que j'ai la flemme de taper. J'en fais un hash MD5 que j'envoies au destinataire par une autre voie sécurisée. Disons que tu interceptes la communication et que tu souhaites m'envoyer un faux message. Il te faut donc créer un autre message _intelligible_ qui ait le même hash MD5. Comme tu l'as écrit, il y en a une foultitude. Par contre, la probabilité que parmis cette foultitude il y en ait un seul qui soit intelligible et qui contienne du texte intéressant pour toi est tout simplement quasiment nulle. Ou du moins, la puissance de calcul nécessaire pour le calculer est gigantesque, si jamais la collision correcte existe. Donc, il t'es impossible de falsifier un message dont le destinataire possède le hash MD5. Même si des collisions existent, comme tu le soulignes. Il est fort improbable que ces collisions aient un sens dans le langage utilisé à l'origine (ascii, binaire, ou autre) C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas facile de trouver des collisions, mais les chances que ces collisions soient exploitables sont nulles...
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
JGP_NoMail
[SNIP]
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, ---------^^^^^^
Si je puis me permettre 17 octets c'est 2^136, Le Hash MD5 (16 octets) c'est 2^128 empreintes différentes, il n'y aura donc que 2^(136-128) = 256 collisions et PAS 16^15.
[SNIP]
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,
---------^^^^^^
Si je puis me permettre 17 octets c'est 2^136, Le Hash MD5 (16 octets)
c'est 2^128 empreintes différentes, il n'y aura donc que 2^(136-128) =
256 collisions et PAS 16^15.
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, ---------^^^^^^
Si je puis me permettre 17 octets c'est 2^136, Le Hash MD5 (16 octets) c'est 2^128 empreintes différentes, il n'y aura donc que 2^(136-128) = 256 collisions et PAS 16^15.
Eric CHAPUZOT
"T0t0" a écrit dans le message de
Même si des collisions existent, comme tu le soulignes. Il est fort improbable que ces collisions aient un sens dans le langage utilisé à l'origine (ascii, binaire, ou autre) C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas facile de trouver des collisions, mais les chances que ces collisions soient exploitables sont nulles...
bah, il suffit de faire jouer les infinis contre les infinis... une manière visible serait de mettre ton message avec 16 caractères de plus genre 0000 0000 0000 0000
genre 999 et 1999 se valent si on ne regarde que les 3 derniers chiffres... simple addition... chuis d'ailleurs en de me creuser la tête pour faire la simple soustraction genre 999 999-md(5) y a forcément une table opérationnelle mais sur 16^15 entrées, ca fait un genre 4 Go seulement.... mais c'est pas trop élégant comme cassage... je devrais.
"T0t0" <bibi@antionline.org> a écrit dans le message de
Même si des collisions existent, comme tu le soulignes. Il est
fort improbable que ces collisions aient un sens dans le langage
utilisé à l'origine (ascii, binaire, ou autre)
C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas
facile de trouver des collisions, mais les chances que ces
collisions soient exploitables sont nulles...
bah, il suffit de faire jouer les infinis contre les infinis...
une manière visible serait de mettre ton message avec 16 caractères de plus
genre 0000 0000 0000 0000
genre 999 et 1999 se valent si on ne regarde que les 3 derniers chiffres...
simple addition...
chuis d'ailleurs en de me creuser la tête pour faire la simple soustraction
genre 999 999-md(5)
y a forcément une table opérationnelle mais sur 16^15 entrées, ca fait un
genre 4 Go seulement....
mais c'est pas trop élégant comme cassage... je devrais.
Même si des collisions existent, comme tu le soulignes. Il est fort improbable que ces collisions aient un sens dans le langage utilisé à l'origine (ascii, binaire, ou autre) C'est ce qui fait la force d'un hash MD5. D'une part il n'est pas facile de trouver des collisions, mais les chances que ces collisions soient exploitables sont nulles...
bah, il suffit de faire jouer les infinis contre les infinis... une manière visible serait de mettre ton message avec 16 caractères de plus genre 0000 0000 0000 0000
genre 999 et 1999 se valent si on ne regarde que les 3 derniers chiffres... simple addition... chuis d'ailleurs en de me creuser la tête pour faire la simple soustraction genre 999 999-md(5) y a forcément une table opérationnelle mais sur 16^15 entrées, ca fait un genre 4 Go seulement.... mais c'est pas trop élégant comme cassage... je devrais.
Eric CHAPUZOT
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux choses, réalisant "en apparence" la même fonction, mais différentes de l'original (trojan, modification des données,...) donnant la même somme md5. C'est déja beaucoup plus délicat, non ?
haha, imaginer, je peux très bien... réaliser, c'est juste un tout petit peu plus compliqué... enfin, à moins de ne pas jouer à 'Alice aux pays des merveilles' pour ceux qui n'aiment pas le langage fleuri des contes : s'adapter à la mesure du problème.
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une
image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux
choses, réalisant "en apparence" la même fonction, mais différentes
de l'original (trojan, modification des données,...) donnant la
même somme md5. C'est déja beaucoup plus délicat, non ?
haha, imaginer, je peux très bien... réaliser, c'est juste un tout petit peu
plus compliqué...
enfin, à moins de ne pas jouer à 'Alice aux pays des merveilles'
pour ceux qui n'aiment pas le langage fleuri des contes : s'adapter à la
mesure du problème.
Mais ça aide bien quand même. Imagine un .tar.gz avec dedans une image .BMP 16 couleurs et 300 lignes de perl. Va produire ces deux choses, réalisant "en apparence" la même fonction, mais différentes de l'original (trojan, modification des données,...) donnant la même somme md5. C'est déja beaucoup plus délicat, non ?
haha, imaginer, je peux très bien... réaliser, c'est juste un tout petit peu plus compliqué... enfin, à moins de ne pas jouer à 'Alice aux pays des merveilles' pour ceux qui n'aiment pas le langage fleuri des contes : s'adapter à la mesure du problème.
