Ca peut relancer aussi le concept du mélange de deux fonctions de
hachage différentes, mais je ne sais pas d'un point de vue théorique
quelle est vraiment la solidité de ce type de méthode.
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
Ca peut relancer aussi le concept du mélange de deux fonctions de
hachage différentes, mais je ne sais pas d'un point de vue théorique
quelle est vraiment la solidité de ce type de méthode.
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
Ca peut relancer aussi le concept du mélange de deux fonctions de
hachage différentes, mais je ne sais pas d'un point de vue théorique
quelle est vraiment la solidité de ce type de méthode.
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
Remarque : j'avance des idées, interrompez quand je dis faux ;)
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
Remarque : j'avance des idées, interrompez quand je dis faux ;)
D'un point de vue théorique, on a beaucoup de mal à bien définir ce que
ça veut dire, que deux fonctions de hachage sont "différentes".
Remarque : j'avance des idées, interrompez quand je dis faux ;)
En bref, je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment. Le mieux serait que SHA-1 tienne une dizaine d'années
de plus, qu'on ait le temps de s'assurer que SHA-256 est bon, et de se
mettre à conseiller d'utiliser SHA-256.
En bref, je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment. Le mieux serait que SHA-1 tienne une dizaine d'années
de plus, qu'on ait le temps de s'assurer que SHA-256 est bon, et de se
mettre à conseiller d'utiliser SHA-256.
En bref, je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment. Le mieux serait que SHA-1 tienne une dizaine d'années
de plus, qu'on ait le temps de s'assurer que SHA-256 est bon, et de se
mettre à conseiller d'utiliser SHA-256.
À supposer que SHA-1 "tombe" comme vient de le faire MD5, que penser d'une
double signature (en attendant mieux) ? Par exemple, serait-il possible de
créer deux fichiers ayant *à* *la* *fois* les mêms signatures MD5 et SHA-1 ?
À supposer que SHA-1 "tombe" comme vient de le faire MD5, que penser d'une
double signature (en attendant mieux) ? Par exemple, serait-il possible de
créer deux fichiers ayant *à* *la* *fois* les mêms signatures MD5 et SHA-1 ?
À supposer que SHA-1 "tombe" comme vient de le faire MD5, que penser d'une
double signature (en attendant mieux) ? Par exemple, serait-il possible de
créer deux fichiers ayant *à* *la* *fois* les mêms signatures MD5 et SHA-1 ?
les conséquences (des récentes attaques sur MD5, MD4, SHA-0.. sont)
catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
les conséquences (des récentes attaques sur MD5, MD4, SHA-0.. sont)
catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
les conséquences (des récentes attaques sur MD5, MD4, SHA-0.. sont)
catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment.
je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment.
je n'ai personnellement rien de mieux à proposer que SHA-1
pour le moment.
Jean-Marie Delapierre dit:les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Relativisons.
D'abord l'algorithme de hash le plus utilisé, et de loin, pour signer des
documents, c'est SHA-1, pas MD5. SHA-1 reste sur pour l'instant.
MD5 reste encore assez utilisé pour les certificats SSL (de https
par exemple), mais dans ce contexte les récentes attaques ont peu de
portée. En effet ces attaques permettent de trouver des collisions,
mais:
- les hashs (donc certificats) EXISTANTS utilisant MD5 ne sont pas
attaquable par quelque technique de collision que ce soit (il faut
une attaque de type [seconde] préimage);
- la pratique existante chez, par exemple, Verisign, quand ils émettent
(encore) un certificat avec MD5, est de mettre de l'aléa au début
du certificat, ce qui également rend inopérante toute attaque par
collision;
- certains (par exemple au moins un utilisateur de OpenSSL postant
des challenges sur nos forums, il se reconnaitra) ne prennent
pas cette précaution; ils sont donc vulnérables à une attaque
connue, en 2^65 calculs MD5 (certe d'un coût de l'ordre de 10^5 euro
à monter), dès lors qu'ils acceptent de signer un certificat pour une
clé publique qu'ils n'ont pas généré; eh bien ces imprudents sont
apparemment assez à l'abris de la nouvelle attaque, qui ne permet PAS
(au contraire de la force brute) de choisir des contenus distincts
au début des données.
MD5 est très utilisé dans HMAC-MD5, mais là aussi les attaques par
collision ne sont pas à craindre.
Ces attaques sont donc une très grande nouvelle, mais pas la fin
du commerce électronique. Par contre, la chute de SHA-1, ou une attaque
de type [seconde] préimage contre MD5, ou même une attaque de type
collision sur MD5 permettant de choisir le début des messages, ou
de ne devoir imposer que quelques bits au lieu de 1024, ce serait
nettement plus gênant.
Ah mon avis, une des pires conséquence réelle de ces attques est qu'il
devient extrèmement facile de faire deux exécutables qui ont le même
hash MD5, mais font deux choses très différentes et que l'on a choisi.
Et aussi, il y a l'impact médiatico/marketing: une aubaine
pour les journaleux et les vendeurs de machins de sécurité, qui vont
pouvoir vendre leur soupe; ça va en pisser de l'article et de l'upgrade !
[Je devrais peut-être pas cracher tant dans la soupe: je vends mes
services comme expert..]
François Grieu
Jean-Marie Delapierre <jm.delapierre@9online.fr> dit:
les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Relativisons.
D'abord l'algorithme de hash le plus utilisé, et de loin, pour signer des
documents, c'est SHA-1, pas MD5. SHA-1 reste sur pour l'instant.
MD5 reste encore assez utilisé pour les certificats SSL (de https
par exemple), mais dans ce contexte les récentes attaques ont peu de
portée. En effet ces attaques permettent de trouver des collisions,
mais:
- les hashs (donc certificats) EXISTANTS utilisant MD5 ne sont pas
attaquable par quelque technique de collision que ce soit (il faut
une attaque de type [seconde] préimage);
- la pratique existante chez, par exemple, Verisign, quand ils émettent
(encore) un certificat avec MD5, est de mettre de l'aléa au début
du certificat, ce qui également rend inopérante toute attaque par
collision;
- certains (par exemple au moins un utilisateur de OpenSSL postant
des challenges sur nos forums, il se reconnaitra) ne prennent
pas cette précaution; ils sont donc vulnérables à une attaque
connue, en 2^65 calculs MD5 (certe d'un coût de l'ordre de 10^5 euro
à monter), dès lors qu'ils acceptent de signer un certificat pour une
clé publique qu'ils n'ont pas généré; eh bien ces imprudents sont
apparemment assez à l'abris de la nouvelle attaque, qui ne permet PAS
(au contraire de la force brute) de choisir des contenus distincts
au début des données.
MD5 est très utilisé dans HMAC-MD5, mais là aussi les attaques par
collision ne sont pas à craindre.
Ces attaques sont donc une très grande nouvelle, mais pas la fin
du commerce électronique. Par contre, la chute de SHA-1, ou une attaque
de type [seconde] préimage contre MD5, ou même une attaque de type
collision sur MD5 permettant de choisir le début des messages, ou
de ne devoir imposer que quelques bits au lieu de 1024, ce serait
nettement plus gênant.
Ah mon avis, une des pires conséquence réelle de ces attques est qu'il
devient extrèmement facile de faire deux exécutables qui ont le même
hash MD5, mais font deux choses très différentes et que l'on a choisi.
Et aussi, il y a l'impact médiatico/marketing: une aubaine
pour les journaleux et les vendeurs de machins de sécurité, qui vont
pouvoir vendre leur soupe; ça va en pisser de l'article et de l'upgrade !
[Je devrais peut-être pas cracher tant dans la soupe: je vends mes
services comme expert..]
François Grieu
Jean-Marie Delapierre dit:les conséquences sont minimes, non ?
Et bien non, les conséquences sont au contraire catastrophiques.
En effet, les algorithmes de hachage sont massivement utilisés dans les
mécanismes de signatures.
Si je sais créer input2 très voisin de input1, qu'est ce qui m'empèche
d'ajouter quelques 0 (à mon avantage bien sur) sur un document
commercial, quitte à introduire quelques fôtes d'orthographe par-ci
par-là ?. C'est la fin programmée, au moins pour quelques années, du
commerce électronique.
Relativisons.
D'abord l'algorithme de hash le plus utilisé, et de loin, pour signer des
documents, c'est SHA-1, pas MD5. SHA-1 reste sur pour l'instant.
MD5 reste encore assez utilisé pour les certificats SSL (de https
par exemple), mais dans ce contexte les récentes attaques ont peu de
portée. En effet ces attaques permettent de trouver des collisions,
mais:
- les hashs (donc certificats) EXISTANTS utilisant MD5 ne sont pas
attaquable par quelque technique de collision que ce soit (il faut
une attaque de type [seconde] préimage);
- la pratique existante chez, par exemple, Verisign, quand ils émettent
(encore) un certificat avec MD5, est de mettre de l'aléa au début
du certificat, ce qui également rend inopérante toute attaque par
collision;
- certains (par exemple au moins un utilisateur de OpenSSL postant
des challenges sur nos forums, il se reconnaitra) ne prennent
pas cette précaution; ils sont donc vulnérables à une attaque
connue, en 2^65 calculs MD5 (certe d'un coût de l'ordre de 10^5 euro
à monter), dès lors qu'ils acceptent de signer un certificat pour une
clé publique qu'ils n'ont pas généré; eh bien ces imprudents sont
apparemment assez à l'abris de la nouvelle attaque, qui ne permet PAS
(au contraire de la force brute) de choisir des contenus distincts
au début des données.
MD5 est très utilisé dans HMAC-MD5, mais là aussi les attaques par
collision ne sont pas à craindre.
Ces attaques sont donc une très grande nouvelle, mais pas la fin
du commerce électronique. Par contre, la chute de SHA-1, ou une attaque
de type [seconde] préimage contre MD5, ou même une attaque de type
collision sur MD5 permettant de choisir le début des messages, ou
de ne devoir imposer que quelques bits au lieu de 1024, ce serait
nettement plus gênant.
Ah mon avis, une des pires conséquence réelle de ces attques est qu'il
devient extrèmement facile de faire deux exécutables qui ont le même
hash MD5, mais font deux choses très différentes et que l'on a choisi.
Et aussi, il y a l'impact médiatico/marketing: une aubaine
pour les journaleux et les vendeurs de machins de sécurité, qui vont
pouvoir vendre leur soupe; ça va en pisser de l'article et de l'upgrade !
[Je devrais peut-être pas cracher tant dans la soupe: je vends mes
services comme expert..]
François Grieu
Accessoirement si tu tiens à ta clef privée je te conseille fortement de
signer le hashé d'un message que je te propose et non pas le message lui
même.
Accessoirement si tu tiens à ta clef privée je te conseille fortement de
signer le hashé d'un message que je te propose et non pas le message lui
même.
Accessoirement si tu tiens à ta clef privée je te conseille fortement de
signer le hashé d'un message que je te propose et non pas le message lui
même.
