1) l'attaquant est libre de choisir une (ou des) courte(s) section(s) du message (de l'ordre de 128 octets chacune) qui sera la seule (ou seront les seules) où diffèreront les deux messages (l'emplacement de la ou des sections dans le message peut être imposé à l'attaquant, dans ce cas la taille de section augmente de moitié)
128 octets, c'est pas largement suffisant pour inserer un shellcode dans un programme?
Cette question n'a pas grand sens: si l'attaquant doit mettre ledit "shellcode" dans un segment de 128 octets où les fichiers *diffèrent*, il n'est plus libre de libre de choisir ces 128 octets, et donc l'attaque ne s'applique pas.
Observations simplificatrices (?) mais exactes:
- l'attaque ne permet PAS de modifier un fichier arbitraire sans en changer le hash.
- l'attaque ne permet PAS de générer un fichier ayant un hash arbitraire.
- l'attaque permet de générer DEUX fichiers qui ont le même hash (facilement pour MD5 et SHA-0, théoriquement pour l'instant pour SHA-1).
- ces DEUX fichiers peuvent par exemple contenir CHACUN un "shellcode" ET un autre code, tous deux arbitraires, et un aiguillage pour que le premier fichier soit un programme qui exécute le "shellcode", et l'autre fichier un programme qui exécute l'autre code.
Conclusion désabusée: après je ne sais combien de messages sur le sujet, je ne parviens pas à faire passer dans quels cas, finalement rares, les nouvelles attaques s'appliquent.
François Grieu
case <case@construct.ath.cx> écrit:
Francois Grieu wrote:
1) l'attaquant est libre de choisir une (ou des)
courte(s) section(s) du message (de l'ordre de 128
octets chacune) qui sera la seule (ou seront les seules)
où diffèreront les deux messages (l'emplacement de la ou
des sections dans le message peut être imposé à
l'attaquant, dans ce cas la taille de section augmente
de moitié)
128 octets, c'est pas largement suffisant pour inserer un
shellcode dans un programme?
Cette question n'a pas grand sens: si l'attaquant doit
mettre ledit "shellcode" dans un segment de 128 octets
où les fichiers *diffèrent*, il n'est plus libre de
libre de choisir ces 128 octets, et donc l'attaque ne
s'applique pas.
Observations simplificatrices (?) mais exactes:
- l'attaque ne permet PAS de modifier un fichier arbitraire
sans en changer le hash.
- l'attaque ne permet PAS de générer un fichier ayant un
hash arbitraire.
- l'attaque permet de générer DEUX fichiers qui ont le
même hash (facilement pour MD5 et SHA-0, théoriquement
pour l'instant pour SHA-1).
- ces DEUX fichiers peuvent par exemple contenir CHACUN
un "shellcode" ET un autre code, tous deux arbitraires,
et un aiguillage pour que le premier fichier soit un
programme qui exécute le "shellcode", et l'autre fichier
un programme qui exécute l'autre code.
Conclusion désabusée: après je ne sais combien de messages
sur le sujet, je ne parviens pas à faire passer dans quels
cas, finalement rares, les nouvelles attaques s'appliquent.
1) l'attaquant est libre de choisir une (ou des) courte(s) section(s) du message (de l'ordre de 128 octets chacune) qui sera la seule (ou seront les seules) où diffèreront les deux messages (l'emplacement de la ou des sections dans le message peut être imposé à l'attaquant, dans ce cas la taille de section augmente de moitié)
128 octets, c'est pas largement suffisant pour inserer un shellcode dans un programme?
Cette question n'a pas grand sens: si l'attaquant doit mettre ledit "shellcode" dans un segment de 128 octets où les fichiers *diffèrent*, il n'est plus libre de libre de choisir ces 128 octets, et donc l'attaque ne s'applique pas.
Observations simplificatrices (?) mais exactes:
- l'attaque ne permet PAS de modifier un fichier arbitraire sans en changer le hash.
- l'attaque ne permet PAS de générer un fichier ayant un hash arbitraire.
- l'attaque permet de générer DEUX fichiers qui ont le même hash (facilement pour MD5 et SHA-0, théoriquement pour l'instant pour SHA-1).
- ces DEUX fichiers peuvent par exemple contenir CHACUN un "shellcode" ET un autre code, tous deux arbitraires, et un aiguillage pour que le premier fichier soit un programme qui exécute le "shellcode", et l'autre fichier un programme qui exécute l'autre code.
Conclusion désabusée: après je ne sais combien de messages sur le sujet, je ne parviens pas à faire passer dans quels cas, finalement rares, les nouvelles attaques s'appliquent.
François Grieu
Francois Grieu
Alain dit
d'autre part j'avais cru lire que cette attaque permettait à partir de 2 messages aussi différent que l'on souhaite, de générer des versions légèrementes différentes (sur seulement 128(192fixes) octets)...
J'imagine que vous voulez dire: que cette attaque permettait à partir de 2 messages aussi différent que l'on souhaite, de générer des versions légèrement différentes (sur seulement 128(192fixes) octets) de chacun des 2 messages, et qu'elles aient le même hash.
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
pratiquement "un Escroc" pourrait ecrire un contrat B1, "bonne affaire", et A1 "arnaque", en réservant 128/192 octets libres dans le contenu (données cachées dans Word, espaces ou données inutiles comme le nom de participants, ou numéro de série, dans texte ou xml) ... ensuite avec l'algo on modifie les deux contrats en B2 et A2 pour qu'ils partagent le même hash H(A2)=H(B2), tout en ayant la même signification utile que A1 et B1 respectivement enfin on fait signer B2 par "le Couillon"... et plus tard on présente A2 en justice en disant que "le Couillon" a signé ! est-ce bien ca ?...
Non.
L'escroc doit construire un fichier contenant à la fois "bonne affaire" et "arnaque", et affichant (et/ou imprimant) l'un ou l'autre selon la valeur dans un bloc que l'attaque modifie. C'est facile si le fichier est du code exécutable, et envisageable si c'est du code interprété (Postscript, PDF, Javascript, Java, Visual Basic..). Avec du texte brut, cela n'est pas possible. Avec un document Word, je ne connais pas de démonstration, mais il faut supposer que c'est possible.
quel est le nombre de round pour générer une paire frauduleuse de contenu chiffré ? est-ce inférieur ou proche de 2^64, ou loin au dessus?
2^69, selon un article publié http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf
2^63, selon une amélioration non publiée http://www.iacr.org/conferences/crypto2005/r/2.pdf
En tout cas bien moins que le 2^80 de la force brute.
François Grieu
Alain <none@none.org> dit
d'autre part j'avais cru lire que cette attaque permettait à partir de 2
messages aussi différent que l'on souhaite, de générer des versions
légèrementes différentes (sur seulement 128(192fixes) octets)...
J'imagine que vous voulez dire: que cette attaque permettait à partir
de 2 messages aussi différent que l'on souhaite, de générer des versions
légèrement différentes (sur seulement 128(192fixes) octets) de chacun
des 2 messages, et qu'elles aient le même hash.
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire
DEUX messages ayant le même hash, CHACUN différant de l'original sur un
(ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre
les deux messages modifiés portant sur quelques bits par bloc, le contenu
des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
pratiquement "un Escroc" pourrait ecrire un contrat B1, "bonne affaire",
et A1 "arnaque", en réservant 128/192 octets libres dans le contenu
(données cachées dans Word, espaces ou données inutiles comme le nom de
participants, ou numéro de série, dans texte ou xml) ...
ensuite avec l'algo on modifie les deux contrats en B2 et A2 pour qu'ils
partagent le même hash H(A2)=H(B2), tout en ayant la même signification
utile que A1 et B1 respectivement
enfin on fait signer B2 par "le Couillon"... et plus tard on présente A2
en justice en disant que "le Couillon" a signé !
est-ce bien ca ?...
Non.
L'escroc doit construire un fichier contenant à la fois "bonne affaire"
et "arnaque", et affichant (et/ou imprimant) l'un ou l'autre selon la valeur
dans un bloc que l'attaque modifie. C'est facile si le fichier est du code
exécutable, et envisageable si c'est du code interprété (Postscript, PDF,
Javascript, Java, Visual Basic..). Avec du texte brut, cela n'est pas
possible. Avec un document Word, je ne connais pas de démonstration, mais
il faut supposer que c'est possible.
quel est le nombre de round pour générer une paire frauduleuse de contenu
chiffré ? est-ce inférieur ou proche de 2^64, ou loin au dessus?
2^69, selon un article publié
http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf
2^63, selon une amélioration non publiée
http://www.iacr.org/conferences/crypto2005/r/2.pdf
En tout cas bien moins que le 2^80 de la force brute.
d'autre part j'avais cru lire que cette attaque permettait à partir de 2 messages aussi différent que l'on souhaite, de générer des versions légèrementes différentes (sur seulement 128(192fixes) octets)...
J'imagine que vous voulez dire: que cette attaque permettait à partir de 2 messages aussi différent que l'on souhaite, de générer des versions légèrement différentes (sur seulement 128(192fixes) octets) de chacun des 2 messages, et qu'elles aient le même hash.
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
pratiquement "un Escroc" pourrait ecrire un contrat B1, "bonne affaire", et A1 "arnaque", en réservant 128/192 octets libres dans le contenu (données cachées dans Word, espaces ou données inutiles comme le nom de participants, ou numéro de série, dans texte ou xml) ... ensuite avec l'algo on modifie les deux contrats en B2 et A2 pour qu'ils partagent le même hash H(A2)=H(B2), tout en ayant la même signification utile que A1 et B1 respectivement enfin on fait signer B2 par "le Couillon"... et plus tard on présente A2 en justice en disant que "le Couillon" a signé ! est-ce bien ca ?...
Non.
L'escroc doit construire un fichier contenant à la fois "bonne affaire" et "arnaque", et affichant (et/ou imprimant) l'un ou l'autre selon la valeur dans un bloc que l'attaque modifie. C'est facile si le fichier est du code exécutable, et envisageable si c'est du code interprété (Postscript, PDF, Javascript, Java, Visual Basic..). Avec du texte brut, cela n'est pas possible. Avec un document Word, je ne connais pas de démonstration, mais il faut supposer que c'est possible.
quel est le nombre de round pour générer une paire frauduleuse de contenu chiffré ? est-ce inférieur ou proche de 2^64, ou loin au dessus?
2^69, selon un article publié http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf
2^63, selon une amélioration non publiée http://www.iacr.org/conferences/crypto2005/r/2.pdf
En tout cas bien moins que le 2^80 de la force brute.
François Grieu
jpeps
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Bonjour.
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu d'envisager un succès avec cette attaque, à ce qu'il me semble.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire
DEUX messages ayant le même hash, CHACUN différant de l'original sur un
(ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre
les deux messages modifiés portant sur quelques bits par bloc, le contenu
des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Bonjour.
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu
d'envisager un succès avec cette attaque, à ce qu'il me semble.
Salutations
JPP
--
Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits
préparés." Louis Pasteur
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Bonjour.
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu d'envisager un succès avec cette attaque, à ce qu'il me semble.
Salutations
JPP
-- Enlevez le NO du spam et .invalid pour me répondre
"Dans les champs de l'observation, le hasard ne favorise que les esprits préparés." Louis Pasteur
Francois Grieu
jpeps a écrit:
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu d'envisager un succès avec cette attaque, à ce qu'il me semble.
En l'état, l'attaque ne permet PAS exactement cela.
En effet les bits qui changent sont perdus dans des blocs dont le contenu est pseudo-aléatoire et imposé par l'algorithme de l'attaque, et non choisi par l'attaquant. Pour prendre une image, il faut un contexte qui permet d'exploiter des messages du genre des deux ci-après:
Contrat : gHbPFh16BHk56YhGuIbn Si le 3ème caractère du bloc précédent est un b, alors le montant du contrat est 20000 E; mais si ce caractère est un c, alors le montant du contrat est 30000 E.
Contrat : gHcPFh16BHk56YhGtIbn Si le 3ème caractère du bloc précédent est un b, alors le montant du contrat est 20000 E; mais si ce caractère est un c, alors le montant du contrat est 30000 E.
De tels contextes existent (par exemple, code exécutable), et Word permet vraissemblement d'en créer (par le jeu de Visual Basic et/ou de language interprété dans les objets encapsulés).
Noter que de ce point de vue l'attaque est moins puissante que la force brute, qui avec envrion 2^81 rounds permet de compléter deux messages arbiraires et complètement distincts pour que les messages complétés aient le même SHA-1.
La différence est d'importance, et fait par exemple que l'autre attaque de Xiaoyun Wang contre MD5 est moins dangereuse dans le contexte de la ceritification X509, que ne l'est la force brute (2^65 rounds), dans certaines implémentations de l'AC, comme OpenSSL.
François Grieu
jpeps <jpeps.NOspam.box@online.fr.invalid> a écrit:
Eh bien, non, l'attaque ne permet PAS cela.
L'attaqe permet de modifier UN message original arbitraire pour produire
DEUX messages ayant le même hash, CHACUN différant de l'original sur un
(ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre
les deux messages modifiés portant sur quelques bits par bloc, le contenu
des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu
d'envisager un succès avec cette attaque, à ce qu'il me semble.
En l'état, l'attaque ne permet PAS exactement cela.
En effet les bits qui changent sont perdus dans des blocs dont le contenu
est pseudo-aléatoire et imposé par l'algorithme de l'attaque, et non choisi
par l'attaquant. Pour prendre une image, il faut un contexte qui permet
d'exploiter des messages du genre des deux ci-après:
Contrat : gHbPFh16BHk56YhGuIbn Si le 3ème caractère du bloc précédent
est un b, alors le montant du contrat est 20000 E; mais si ce caractère
est un c, alors le montant du contrat est 30000 E.
Contrat : gHcPFh16BHk56YhGtIbn Si le 3ème caractère du bloc précédent
est un b, alors le montant du contrat est 20000 E; mais si ce caractère
est un c, alors le montant du contrat est 30000 E.
De tels contextes existent (par exemple, code exécutable), et Word
permet vraissemblement d'en créer (par le jeu de Visual Basic et/ou de
language interprété dans les objets encapsulés).
Noter que de ce point de vue l'attaque est moins puissante que la
force brute, qui avec envrion 2^81 rounds permet de compléter deux
messages arbiraires et complètement distincts pour que les messages
complétés aient le même SHA-1.
La différence est d'importance, et fait par exemple que l'autre attaque
de Xiaoyun Wang contre MD5 est moins dangereuse dans le contexte de la
ceritification X509, que ne l'est la force brute (2^65 rounds), dans
certaines implémentations de l'AC, comme OpenSSL.
L'attaqe permet de modifier UN message original arbitraire pour produire DEUX messages ayant le même hash, CHACUN différant de l'original sur un (ou plusieurs) bloc(s) d'un grosse centaine d'octet, la différence entre les deux messages modifiés portant sur quelques bits par bloc, le contenu des blocs étant imposé par l'attaque (et non choisi par l'attaquant).
Il y a quand même peu de bits différents entre :
Le montant total de la prestation objet de ce contrat est de 1287,47 euros
et
Le montant total de la prestation objet de ce contrat est de 1287447 euros
Noyé dans une dizaine de pages MS WORD "conçues pour", il n'est pas exclu d'envisager un succès avec cette attaque, à ce qu'il me semble.
En l'état, l'attaque ne permet PAS exactement cela.
En effet les bits qui changent sont perdus dans des blocs dont le contenu est pseudo-aléatoire et imposé par l'algorithme de l'attaque, et non choisi par l'attaquant. Pour prendre une image, il faut un contexte qui permet d'exploiter des messages du genre des deux ci-après:
Contrat : gHbPFh16BHk56YhGuIbn Si le 3ème caractère du bloc précédent est un b, alors le montant du contrat est 20000 E; mais si ce caractère est un c, alors le montant du contrat est 30000 E.
Contrat : gHcPFh16BHk56YhGtIbn Si le 3ème caractère du bloc précédent est un b, alors le montant du contrat est 20000 E; mais si ce caractère est un c, alors le montant du contrat est 30000 E.
De tels contextes existent (par exemple, code exécutable), et Word permet vraissemblement d'en créer (par le jeu de Visual Basic et/ou de language interprété dans les objets encapsulés).
Noter que de ce point de vue l'attaque est moins puissante que la force brute, qui avec envrion 2^81 rounds permet de compléter deux messages arbiraires et complètement distincts pour que les messages complétés aient le même SHA-1.
La différence est d'importance, et fait par exemple que l'autre attaque de Xiaoyun Wang contre MD5 est moins dangereuse dans le contexte de la ceritification X509, que ne l'est la force brute (2^65 rounds), dans certaines implémentations de l'AC, comme OpenSSL.
