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?
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.
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.
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...
Meuh oui. Et tu penses donc que le père Rivest il ne connait pas les tables de Carnaugh... Et tu penses également que le père Rivest il ne sait pas rendre non linéaires ses transformations, de sorte que ce que tu 'espères' faire tombera forcément à l'eau...
"Rivest est un crétin, c'est bien connu." (c) 2004 Pr Eric Chapuzot.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- TP> Les binaires sur fr.* ne sont pas envisageables pour diverses TP> raisons techniques qui ont déjà été évoquées des centaines de fois. Les techniques que tu évoques sont des techniques de ta mère. -+- C in GNU - Ta mère en short elle administre un serveur de niouzes -
On 18 May 2004, Eric CHAPUZOT wrote:
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.
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.
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...
Meuh oui. Et tu penses donc que le père Rivest il ne connait pas les
tables de Carnaugh... Et tu penses également que le père Rivest il ne sait
pas rendre non linéaires ses transformations, de sorte que ce que tu
'espères' faire tombera forcément à l'eau...
"Rivest est un crétin, c'est bien connu." (c) 2004 Pr Eric Chapuzot.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
TP> Les binaires sur fr.* ne sont pas envisageables pour diverses
TP> raisons techniques qui ont déjà été évoquées des centaines de fois.
Les techniques que tu évoques sont des techniques de ta mère.
-+- C in GNU - Ta mère en short elle administre un serveur de niouzes -
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.
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.
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...
Meuh oui. Et tu penses donc que le père Rivest il ne connait pas les tables de Carnaugh... Et tu penses également que le père Rivest il ne sait pas rendre non linéaires ses transformations, de sorte que ce que tu 'espères' faire tombera forcément à l'eau...
"Rivest est un crétin, c'est bien connu." (c) 2004 Pr Eric Chapuzot.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- TP> Les binaires sur fr.* ne sont pas envisageables pour diverses TP> raisons techniques qui ont déjà été évoquées des centaines de fois. Les techniques que tu évoques sont des techniques de ta mère. -+- C in GNU - Ta mère en short elle administre un serveur de niouzes -
Kupee
Alain Montfranc wrote:
comment faire pour une personne A pour envoyer un message md5 que seule une personne B pourra décoder ?
si tu trouves tu es bon pour le Nobel
Et pourtant il y a une infinité de solutions qui donneront un même MD5. Le truc est qu'une seule est la bonne, et que trouver une solution reste difficile même s'il y en a une infinité
Alain Montfranc wrote:
comment faire pour une personne A pour envoyer un message md5 que
seule une
personne B pourra décoder ?
si tu trouves tu es bon pour le Nobel
Et pourtant il y a une infinité de solutions qui donneront un même MD5.
Le truc est qu'une seule est la bonne, et que trouver une solution reste
difficile même s'il y en a une infinité
comment faire pour une personne A pour envoyer un message md5 que seule une personne B pourra décoder ?
si tu trouves tu es bon pour le Nobel
Et pourtant il y a une infinité de solutions qui donneront un même MD5. Le truc est qu'une seule est la bonne, et que trouver une solution reste difficile même s'il y en a une infinité
Stephane Catteau
Eric CHAPUZOT nous disait récement dans fr.comp.securite <news:40aa20b7$0$19658$ :
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... [...]
C'est-à-dire nul part.
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é...
Comme je te l'ai dit dans ma précédente réponse, tu confonds hashage et cryptage, voire simple codage puisque ce que tu dis ne serait vrai que dans ce dernier cas. En effet, il n'y a que dans ce cas que l'on peut s'appuyer sur le fait que xyz = abc pour arriver à recomposer le résultat. Dans le cas d'un cryptage, un algorithme divinatoire, appuyé éventuellement d'une table d'éléments récursifs ou fixe, permettrait d'utiliser cette méthode pour deviner la clé et/ou les données cryptées *si* il y a une faiblesse dans l'algorithme. Mais dans le cas d'un hashage, la seule chose qui puisse te permettre de passer outre et de casser le résultat (et non les données elles-mêmes) est une collision. Ce que tu reconnais toi-même sans pour autant arriver à exploiter cette réalité.
Compte-tenu de cela, un hash MD5 est potentiellement inviolable dans le cas d'une somme de contrôle. Tout simplement parce qu'il faudrait un énorme coup de chance pour arriver à altérer les données tout en obtenant le même résultat. En effet, la prédiction n'étant pas applicable dans le cas d'un hash, il n'est pas possible de savoir ce qu'il faudra rajouter au données altérées pour obtenir un hash MD5 correspondant à celui des données originales. De même, de part le principe du hashage les collisions sont nombreuses (mais indétectables tant que l'on n'est pas tombé dessus) dans les 2^64[1] chaînes de 16 octets. Du coup, il n'est pas possible de faire comme pour un CRC, par exemple, et rajouter X octets d'une valeur précise pour retomber sur ses pattes, c'est-à-dire la somme de contrôle des données d'origine.
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est dans le cas d'un mot de passe. En effet, il suffit de connaitre une chaîne ayant le même résultat après hashage pour arriver à passer outre. Cependant, compte-tenu des collisions pré-citées, ce ne sont pas les hash MD5 des 2^64 chaînes de 16 octets qu'il faudra préalablement calculer et stocker, mais probablement les 2^128 chaînes de 32 octets, voir les 2^172 chaînes de 48 octets, voir les 2^256 chaînes de 64 octets ; voir beaucoup plus encore, car rien ne permet de prédire qu'il n'existe pas au moins un hash qui n'est généré que par des chaînes de plus de X octets (avec X supérieur à 48). Et c'est là la force d'un hashage, l'absence totale de prédictibilité. Générer une table contenant 2^64 entrées, chacune constituée d'une chaîne générant un hash MD5 unique est faisable, pour qui dispose du temps nécessaire et d'un espace de stockage suffisant. Cependant, s'il suffit probablement de 26 essais pour trouver 26 hashs différents, il faudra en théorie 2^infini essais pour obtenir les 2^64 hashs différents et ainsi avoir une table utilisable. Sachant, évidement, que chaque chaîne aura une longueur aléatoire, ce qui compliquera un peu l'indexation et l'utilisation de la table.
[1] Ca fait du bien de dormir, on a les idées plus claires après ;-) -- Ô ma douce, comme te sied la pâle lueur des leds De mon switch. Ainsi éclairée, point tu n'es laide... Y a pas, ça en jette ;-) -+- SC in GFD - "Freebox allons voir si la rose..." -+-
Eric CHAPUZOT nous disait récement dans fr.comp.securite
<news:40aa20b7$0$19658$4d4eb98e@read.news.fr.uu.net> :
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... [...]
C'est-à-dire nul part.
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é...
Comme je te l'ai dit dans ma précédente réponse, tu confonds hashage
et cryptage, voire simple codage puisque ce que tu dis ne serait vrai
que dans ce dernier cas. En effet, il n'y a que dans ce cas que l'on
peut s'appuyer sur le fait que xyz = abc pour arriver à recomposer le
résultat. Dans le cas d'un cryptage, un algorithme divinatoire, appuyé
éventuellement d'une table d'éléments récursifs ou fixe, permettrait
d'utiliser cette méthode pour deviner la clé et/ou les données cryptées
*si* il y a une faiblesse dans l'algorithme. Mais dans le cas d'un
hashage, la seule chose qui puisse te permettre de passer outre et de
casser le résultat (et non les données elles-mêmes) est une collision.
Ce que tu reconnais toi-même sans pour autant arriver à exploiter cette
réalité.
Compte-tenu de cela, un hash MD5 est potentiellement inviolable dans
le cas d'une somme de contrôle. Tout simplement parce qu'il faudrait un
énorme coup de chance pour arriver à altérer les données tout en
obtenant le même résultat. En effet, la prédiction n'étant pas
applicable dans le cas d'un hash, il n'est pas possible de savoir ce
qu'il faudra rajouter au données altérées pour obtenir un hash MD5
correspondant à celui des données originales. De même, de part le
principe du hashage les collisions sont nombreuses (mais indétectables
tant que l'on n'est pas tombé dessus) dans les 2^64[1] chaînes de 16
octets. Du coup, il n'est pas possible de faire comme pour un CRC, par
exemple, et rajouter X octets d'une valeur précise pour retomber sur
ses pattes, c'est-à-dire la somme de contrôle des données d'origine.
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est
dans le cas d'un mot de passe. En effet, il suffit de connaitre une
chaîne ayant le même résultat après hashage pour arriver à passer
outre. Cependant, compte-tenu des collisions pré-citées, ce ne sont pas
les hash MD5 des 2^64 chaînes de 16 octets qu'il faudra préalablement
calculer et stocker, mais probablement les 2^128 chaînes de 32 octets,
voir les 2^172 chaînes de 48 octets, voir les 2^256 chaînes de 64
octets ; voir beaucoup plus encore, car rien ne permet de prédire qu'il
n'existe pas au moins un hash qui n'est généré que par des chaînes de
plus de X octets (avec X supérieur à 48). Et c'est là la force d'un
hashage, l'absence totale de prédictibilité.
Générer une table contenant 2^64 entrées, chacune constituée d'une
chaîne générant un hash MD5 unique est faisable, pour qui dispose du
temps nécessaire et d'un espace de stockage suffisant. Cependant, s'il
suffit probablement de 26 essais pour trouver 26 hashs différents, il
faudra en théorie 2^infini essais pour obtenir les 2^64 hashs
différents et ainsi avoir une table utilisable. Sachant, évidement, que
chaque chaîne aura une longueur aléatoire, ce qui compliquera un peu
l'indexation et l'utilisation de la table.
[1]
Ca fait du bien de dormir, on a les idées plus claires après ;-)
--
Ô ma douce, comme te sied la pâle lueur des leds
De mon switch. Ainsi éclairée, point tu n'es laide...
Y a pas, ça en jette ;-)
-+- SC in GFD - "Freebox allons voir si la rose..." -+-
Eric CHAPUZOT nous disait récement dans fr.comp.securite <news:40aa20b7$0$19658$ :
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... [...]
C'est-à-dire nul part.
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é...
Comme je te l'ai dit dans ma précédente réponse, tu confonds hashage et cryptage, voire simple codage puisque ce que tu dis ne serait vrai que dans ce dernier cas. En effet, il n'y a que dans ce cas que l'on peut s'appuyer sur le fait que xyz = abc pour arriver à recomposer le résultat. Dans le cas d'un cryptage, un algorithme divinatoire, appuyé éventuellement d'une table d'éléments récursifs ou fixe, permettrait d'utiliser cette méthode pour deviner la clé et/ou les données cryptées *si* il y a une faiblesse dans l'algorithme. Mais dans le cas d'un hashage, la seule chose qui puisse te permettre de passer outre et de casser le résultat (et non les données elles-mêmes) est une collision. Ce que tu reconnais toi-même sans pour autant arriver à exploiter cette réalité.
Compte-tenu de cela, un hash MD5 est potentiellement inviolable dans le cas d'une somme de contrôle. Tout simplement parce qu'il faudrait un énorme coup de chance pour arriver à altérer les données tout en obtenant le même résultat. En effet, la prédiction n'étant pas applicable dans le cas d'un hash, il n'est pas possible de savoir ce qu'il faudra rajouter au données altérées pour obtenir un hash MD5 correspondant à celui des données originales. De même, de part le principe du hashage les collisions sont nombreuses (mais indétectables tant que l'on n'est pas tombé dessus) dans les 2^64[1] chaînes de 16 octets. Du coup, il n'est pas possible de faire comme pour un CRC, par exemple, et rajouter X octets d'une valeur précise pour retomber sur ses pattes, c'est-à-dire la somme de contrôle des données d'origine.
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est dans le cas d'un mot de passe. En effet, il suffit de connaitre une chaîne ayant le même résultat après hashage pour arriver à passer outre. Cependant, compte-tenu des collisions pré-citées, ce ne sont pas les hash MD5 des 2^64 chaînes de 16 octets qu'il faudra préalablement calculer et stocker, mais probablement les 2^128 chaînes de 32 octets, voir les 2^172 chaînes de 48 octets, voir les 2^256 chaînes de 64 octets ; voir beaucoup plus encore, car rien ne permet de prédire qu'il n'existe pas au moins un hash qui n'est généré que par des chaînes de plus de X octets (avec X supérieur à 48). Et c'est là la force d'un hashage, l'absence totale de prédictibilité. Générer une table contenant 2^64 entrées, chacune constituée d'une chaîne générant un hash MD5 unique est faisable, pour qui dispose du temps nécessaire et d'un espace de stockage suffisant. Cependant, s'il suffit probablement de 26 essais pour trouver 26 hashs différents, il faudra en théorie 2^infini essais pour obtenir les 2^64 hashs différents et ainsi avoir une table utilisable. Sachant, évidement, que chaque chaîne aura une longueur aléatoire, ce qui compliquera un peu l'indexation et l'utilisation de la table.
[1] Ca fait du bien de dormir, on a les idées plus claires après ;-) -- Ô ma douce, comme te sied la pâle lueur des leds De mon switch. Ainsi éclairée, point tu n'es laide... Y a pas, ça en jette ;-) -+- SC in GFD - "Freebox allons voir si la rose..." -+-
Stephane Catteau
Jacques Caron nous disait récement dans fr.comp.securite <news: :
Un hash MD5 fait 16 octets (32 caractères si on le transcrit en hexa).
Vi vi, j'avais essayé de chasser les brumes d'une nuit blanche pour répondre à l'autre message, mais ça n'a pas été suffisant pour que je fasse abstraction de ce que j'avais sous les yeux :-(
-- Ô ma douce, comme te sied la pâle lueur des leds De mon switch. Ainsi éclairée, point tu n'es laide... Y a pas, ça en jette ;-) -+- SC in GFD - "Freebox allons voir si la rose..." -+-
Jacques Caron nous disait récement dans fr.comp.securite
<news:opr77j7rb1q1hokb@news.free.fr> :
Un hash MD5 fait 16 octets (32 caractères si on le transcrit en
hexa).
Vi vi, j'avais essayé de chasser les brumes d'une nuit blanche pour
répondre à l'autre message, mais ça n'a pas été suffisant pour que je
fasse abstraction de ce que j'avais sous les yeux :-(
--
Ô ma douce, comme te sied la pâle lueur des leds
De mon switch. Ainsi éclairée, point tu n'es laide...
Y a pas, ça en jette ;-)
-+- SC in GFD - "Freebox allons voir si la rose..." -+-
Jacques Caron nous disait récement dans fr.comp.securite <news: :
Un hash MD5 fait 16 octets (32 caractères si on le transcrit en hexa).
Vi vi, j'avais essayé de chasser les brumes d'une nuit blanche pour répondre à l'autre message, mais ça n'a pas été suffisant pour que je fasse abstraction de ce que j'avais sous les yeux :-(
-- Ô ma douce, comme te sied la pâle lueur des leds De mon switch. Ainsi éclairée, point tu n'es laide... Y a pas, ça en jette ;-) -+- SC in GFD - "Freebox allons voir si la rose..." -+-
Etienne de Tocqueville
Fabien LE LEZ a écrit sur fr.comp.securite :
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.
Ma tete a coupé que 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.
En fait, avec 16 octets, on ne couvre pas tout. On couvre statistiquement 1-1/e = 63.212% de l'ensemble des valeurs possible. C'est la limite de 1-[(n-1)/n]^n quand n tend vers l'infini. Je serais bien incapable d'en faire la démonstration théorique, mais comme ça serait HS sur ce forum, ça tombe bien !
Avec 17 octets, on couvre donc 1-1/e^256 de l'ensemble. On a donc 1 chance sur e^256 de ne pas avoir l'élément qu'on cherche, alors que l'ensemble n'a que 2^128 éléments.
La probabilité qu'un élément ne soit pas dans l'ensemble couvert par les 17 octets est donc de 2^128/e^256 soit environ 1 chance sur 10^73. Si on tombe sur ce cas, je veux bien me faire couper la tete ;-)
Mais bon, si j'ai fait une erreur de calcul, je ne me fais pas couper la tete ! Faut pas pousser non plus ;-)
Fabien LE LEZ <gramster@gramster.com> a écrit sur fr.comp.securite :
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.
Ma tete a coupé que 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.
En fait, avec 16 octets, on ne couvre pas tout. On couvre
statistiquement 1-1/e = 63.212% de l'ensemble des valeurs
possible. C'est la limite de 1-[(n-1)/n]^n quand n tend vers
l'infini. Je serais bien incapable d'en faire la démonstration
théorique, mais comme ça serait HS sur ce forum, ça tombe bien !
Avec 17 octets, on couvre donc 1-1/e^256 de l'ensemble. On a donc 1
chance sur e^256 de ne pas avoir l'élément qu'on cherche, alors que
l'ensemble n'a que 2^128 éléments.
La probabilité qu'un élément ne soit pas dans l'ensemble couvert par les
17 octets est donc de 2^128/e^256 soit environ 1 chance sur 10^73. Si on
tombe sur ce cas, je veux bien me faire couper la tete ;-)
Mais bon, si j'ai fait une erreur de calcul, je ne me fais pas couper la
tete ! Faut pas pousser non plus ;-)
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.
Ma tete a coupé que 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.
En fait, avec 16 octets, on ne couvre pas tout. On couvre statistiquement 1-1/e = 63.212% de l'ensemble des valeurs possible. C'est la limite de 1-[(n-1)/n]^n quand n tend vers l'infini. Je serais bien incapable d'en faire la démonstration théorique, mais comme ça serait HS sur ce forum, ça tombe bien !
Avec 17 octets, on couvre donc 1-1/e^256 de l'ensemble. On a donc 1 chance sur e^256 de ne pas avoir l'élément qu'on cherche, alors que l'ensemble n'a que 2^128 éléments.
La probabilité qu'un élément ne soit pas dans l'ensemble couvert par les 17 octets est donc de 2^128/e^256 soit environ 1 chance sur 10^73. Si on tombe sur ce cas, je veux bien me faire couper la tete ;-)
Mais bon, si j'ai fait une erreur de calcul, je ne me fais pas couper la tete ! Faut pas pousser non plus ;-)
Etienne de Tocqueville
Cedric Blancher a écrit sur fr.comp.securite :
Et ceci est d'autant plus vrai que la fonction est extrêmement variable, à savoir que deux messages très proches auront des empreintes complètement différentes, ce qui peut laisser penser (raccourci rapide) que deux messages ayant le même hash soient tellement différent que la confusion ne soit même pas concevable.
Le raccourci est en effet bien rapide ;-)
Si tu as le MD5 d'un programme, tu peux le falsifier à ta guise pour obtenir ce que tu veux, puis choisir 17 octets dont la modification ne changera pas le résultats (par exemple une chaine de caractère quelconque correspondant à un message d'erreur de la libc), et en les faisant varier, tu tombe rapidement sur le MD5 voulu.
Si c'est un document texte, il suffit d'y repérer une 40ène de chiffre que tu peux faire varier sans changer le sens du texte.
Du coup, tu peux obtenir le MD5 que tu souhaite sans pour autant changer la signification du fichier d'origine.
... C'est juste une question de temps ;-)
Cedric Blancher <blancher@cartel-securite.fr> a écrit sur fr.comp.securite :
Et ceci est d'autant plus vrai que la fonction est extrêmement variable,
à savoir que deux messages très proches auront des empreintes
complètement différentes, ce qui peut laisser penser (raccourci rapide)
que deux messages ayant le même hash soient tellement différent que la
confusion ne soit même pas concevable.
Le raccourci est en effet bien rapide ;-)
Si tu as le MD5 d'un programme, tu peux le falsifier à ta guise pour
obtenir ce que tu veux, puis choisir 17 octets dont la modification ne
changera pas le résultats (par exemple une chaine de caractère
quelconque correspondant à un message d'erreur de la libc), et en les
faisant varier, tu tombe rapidement sur le MD5 voulu.
Si c'est un document texte, il suffit d'y repérer une 40ène de chiffre
que tu peux faire varier sans changer le sens du texte.
Du coup, tu peux obtenir le MD5 que tu souhaite sans pour autant changer
la signification du fichier d'origine.
Et ceci est d'autant plus vrai que la fonction est extrêmement variable, à savoir que deux messages très proches auront des empreintes complètement différentes, ce qui peut laisser penser (raccourci rapide) que deux messages ayant le même hash soient tellement différent que la confusion ne soit même pas concevable.
Le raccourci est en effet bien rapide ;-)
Si tu as le MD5 d'un programme, tu peux le falsifier à ta guise pour obtenir ce que tu veux, puis choisir 17 octets dont la modification ne changera pas le résultats (par exemple une chaine de caractère quelconque correspondant à un message d'erreur de la libc), et en les faisant varier, tu tombe rapidement sur le MD5 voulu.
Si c'est un document texte, il suffit d'y repérer une 40ène de chiffre que tu peux faire varier sans changer le sens du texte.
Du coup, tu peux obtenir le MD5 que tu souhaite sans pour autant changer la signification du fichier d'origine.
... C'est juste une question de temps ;-)
Jacques L'helgoualc'h
Stephane Catteau a dit : [...]
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est dans le cas d'un mot de passe. [...] rien ne permet de prédire qu'il n'existe pas au moins un hash qui n'est généré que par des chaînes de plus de X octets (avec X supérieur à 48).
D'un autre côté, devoir retenir un mot de passe de plus de 48 octets... La NSA doit déjà avoir les MD5 de tous les vers enregistrés par le projet Gutenberg ;) -- Jacques L'helgoualc'h 5fe601327aef8bff5c930807a97fbdad
Stephane Catteau <steph.nospam@sc4x.net> a dit :
[...]
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est
dans le cas d'un mot de passe. [...] rien ne permet de prédire qu'il
n'existe pas au moins un hash qui n'est généré que par des chaînes de
plus de X octets (avec X supérieur à 48).
D'un autre côté, devoir retenir un mot de passe de plus de 48
octets... La NSA doit déjà avoir les MD5 de tous les vers
enregistrés par le projet Gutenberg ;)
--
Jacques L'helgoualc'h
5fe601327aef8bff5c930807a97fbdad
Là où un hash MD5 est le plus vulnérable (relativement parlant), c'est dans le cas d'un mot de passe. [...] rien ne permet de prédire qu'il n'existe pas au moins un hash qui n'est généré que par des chaînes de plus de X octets (avec X supérieur à 48).
D'un autre côté, devoir retenir un mot de passe de plus de 48 octets... La NSA doit déjà avoir les MD5 de tous les vers enregistrés par le projet Gutenberg ;) -- Jacques L'helgoualc'h 5fe601327aef8bff5c930807a97fbdad
Emmanuel Florac
Le Wed, 19 May 2004 00:09:58 +0000, Eric CHAPUZOT a écrit :
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...
Si je peux me permettre, vu qu'il y a une infinité de fichiers qui correspondent à un hash md5 donné, il y a forcément une infinité de codes sources qui y correspondent.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Wed, 19 May 2004 00:09:58 +0000, Eric CHAPUZOT a écrit :
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...
Si je peux me permettre, vu qu'il y a une infinité de fichiers qui
correspondent à un hash md5 donné, il y a forcément une infinité de
codes sources qui y correspondent.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Le Wed, 19 May 2004 00:09:58 +0000, Eric CHAPUZOT a écrit :
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...
Si je peux me permettre, vu qu'il y a une infinité de fichiers qui correspondent à un hash md5 donné, il y a forcément une infinité de codes sources qui y correspondent.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Eric CHAPUZOT
"Stephane Catteau" a écrit dans le message de
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... [...]
C'est-à-dire nul part.
tout-à-fait d'accord : on remonte vers du nulle-part mais par la même
occasion ce nulle-part crée une collision md5 puisqu'il a la même empreinte que le quelque chose.
[...laïus sur le stockage... ] vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de
toutes les combinaisons Comme si dans une calculatrice, on stockait tous les résultats des multiplications, additions , divisions et soustractions de tous les nombres à 8 chiffres possibles... ... ca commence à faire vraiment arriéré pour le genre humain.
"Stephane Catteau" <steph.nospam@sc4x.net> a écrit dans le message de
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... [...]
C'est-à-dire nul part.
tout-à-fait d'accord : on remonte vers du nulle-part mais par la même
occasion ce nulle-part crée une collision md5 puisqu'il a la même empreinte
que le quelque chose.
[...laïus sur le stockage... ]
vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de
toutes les combinaisons
Comme si dans une calculatrice, on stockait tous les résultats des
multiplications, additions , divisions et soustractions de tous les nombres
à 8 chiffres possibles...
... ca commence à faire vraiment arriéré pour le genre humain.
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... [...]
C'est-à-dire nul part.
tout-à-fait d'accord : on remonte vers du nulle-part mais par la même
occasion ce nulle-part crée une collision md5 puisqu'il a la même empreinte que le quelque chose.
[...laïus sur le stockage... ] vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de
toutes les combinaisons Comme si dans une calculatrice, on stockait tous les résultats des multiplications, additions , divisions et soustractions de tous les nombres à 8 chiffres possibles... ... ca commence à faire vraiment arriéré pour le genre humain.
Guillermito
On 20 May 2004 10:35:22 GMT, Eric CHAPUZOT wrote:
vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de toutes les combinaisons
C'est pourtant fondamental, et lié.
Le MD5, comme les autres hashs cryptographiques, n'a apparemment pas de faiblesse mathématique évidente qui permettrait de l'attaquer autrement que par force brute.
Et si on attaque par force brute, on doit prendre en compte un nombre de fichiers tellement immense, qu'ils est strictement impossible de les stocker ou d'en calculer leurs hashs dans un temps suffisamment court.
-- Guillermito http://www.guillermito2.net
On 20 May 2004 10:35:22 GMT, Eric CHAPUZOT wrote:
vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de
toutes les combinaisons
C'est pourtant fondamental, et lié.
Le MD5, comme les autres hashs cryptographiques, n'a apparemment pas de
faiblesse mathématique évidente qui permettrait de l'attaquer autrement
que par force brute.
Et si on attaque par force brute, on doit prendre en compte un nombre de
fichiers tellement immense, qu'ils est strictement impossible de les
stocker ou d'en calculer leurs hashs dans un temps suffisamment court.
vous me fatiguez à causer 1)du stockage 2) du calcul en force brute de toutes les combinaisons
C'est pourtant fondamental, et lié.
Le MD5, comme les autres hashs cryptographiques, n'a apparemment pas de faiblesse mathématique évidente qui permettrait de l'attaquer autrement que par force brute.
Et si on attaque par force brute, on doit prendre en compte un nombre de fichiers tellement immense, qu'ils est strictement impossible de les stocker ou d'en calculer leurs hashs dans un temps suffisamment court.
