Mauvaise semaine pour les fonctions de hash (MD5, SHA-0, etc)...
Dans la même veine, cet article qui rapporte une RUMEUR sur une
découverte de collision sur SHA-1 :
http://www.freedom-to-tinker.com/archives/000661.html
Avez-vous vu cela? L'article est clairement alarmiste.
Et quelqu'un a-t-il des nouvelles ? confirmation, infirmation, détails...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lists
Roland wrote:
Dans la même veine, cet article qui rapporte une RUMEUR sur une découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Roland <x-kane@hotmail.com> wrote:
Dans la même veine, cet article qui rapporte une RUMEUR sur une
découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui
ont le même hash ? Cela ne permet pas de modifier à volonté un fichier
existant tout en laissant son hash inchangé, si ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Dans la même veine, cet article qui rapporte une RUMEUR sur une découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Francois Grieu
(Julien Salort) écrit:
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
De fait, l'attaque ne permet pas de modifier un fichier existant tout en laissant son hash inchangé; encore moins de le modifier "a volonté". L'attaque permet de préparer deux messages qui ont le le même hash, mais sont identiques sauf sur un (ou des) segments de 128 octets où l'attaquant est contraint à mettre des valeurs d'apparence assez largement aléatoire, et différant de quelques bits seulement à des endroits bien précis.
Dans certaines contextes, il peut y avoir des "problèmes" réels. Par exemple, il est possible de préparer deux programmes ou deux documents HTML+Javascript, Postscript, PDF, Word... de hash identique, mais qui quand on les exécute/visualise/imprime, disent des choses complètement différentes et toutes deux choisies par l'attaquant: il utilise deux messages du genre - si (azErTy)contient une majuscule) faire ceci sinon cela - si (azerty contient une majuscule) faire ceci sinon cela où azErTy/azerty est un segment du message que l'adversaire peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre, d'où problème si celui qui a construit le message signé avait des intentions délictueuses avant la signature.
François Grieu
lists@juliensalort.org (Julien Salort) écrit:
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui
ont le même hash ? Cela ne permet pas de modifier à volonté un fichier
existant tout en laissant son hash inchangé, si ?
De fait, l'attaque ne permet pas de modifier un fichier existant tout
en laissant son hash inchangé; encore moins de le modifier "a volonté".
L'attaque permet de préparer deux messages qui ont le le même hash,
mais sont identiques sauf sur un (ou des) segments de 128 octets
où l'attaquant est contraint à mettre des valeurs d'apparence
assez largement aléatoire, et différant de quelques bits seulement
à des endroits bien précis.
Dans certaines contextes, il peut y avoir des "problèmes" réels.
Par exemple, il est possible de préparer deux programmes ou deux
documents HTML+Javascript, Postscript, PDF, Word... de hash identique,
mais qui quand on les exécute/visualise/imprime, disent des choses
complètement différentes et toutes deux choisies par l'attaquant:
il utilise deux messages du genre
- si (azErTy)contient une majuscule) faire ceci sinon cela
- si (azerty contient une majuscule) faire ceci sinon cela
où azErTy/azerty est un segment du message que l'adversaire
peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre,
d'où problème si celui qui a construit le message signé avait des
intentions délictueuses avant la signature.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
De fait, l'attaque ne permet pas de modifier un fichier existant tout en laissant son hash inchangé; encore moins de le modifier "a volonté". L'attaque permet de préparer deux messages qui ont le le même hash, mais sont identiques sauf sur un (ou des) segments de 128 octets où l'attaquant est contraint à mettre des valeurs d'apparence assez largement aléatoire, et différant de quelques bits seulement à des endroits bien précis.
Dans certaines contextes, il peut y avoir des "problèmes" réels. Par exemple, il est possible de préparer deux programmes ou deux documents HTML+Javascript, Postscript, PDF, Word... de hash identique, mais qui quand on les exécute/visualise/imprime, disent des choses complètement différentes et toutes deux choisies par l'attaquant: il utilise deux messages du genre - si (azErTy)contient une majuscule) faire ceci sinon cela - si (azerty contient une majuscule) faire ceci sinon cela où azErTy/azerty est un segment du message que l'adversaire peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre, d'où problème si celui qui a construit le message signé avait des intentions délictueuses avant la signature.
François Grieu
Roland
Julien Salort wrote:
Roland wrote:
Dans la même veine, cet article qui rapporte une RUMEUR sur une découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
En plus, les gens sont parano (et ont raison de l'être parfois).
Une attaque par collision peut être un premier signe d'une faiblesse pour un algorithme, faiblesse qui serait utilisée dans le futur pour une attaque complète. Là c'est au cas par cas, mais on pressent un risque plus fort en général...
Julien Salort wrote:
Roland <x-kane@hotmail.com> wrote:
Dans la même veine, cet article qui rapporte une RUMEUR sur une
découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui
ont le même hash ? Cela ne permet pas de modifier à volonté un fichier
existant tout en laissant son hash inchangé, si ?
En plus, les gens sont parano (et ont raison de l'être parfois).
Une attaque par collision peut être un premier signe d'une faiblesse
pour un algorithme, faiblesse qui serait utilisée dans le futur pour une
attaque complète.
Là c'est au cas par cas, mais on pressent un risque plus fort en général...
Dans la même veine, cet article qui rapporte une RUMEUR sur une découverte de collision sur SHA-1
Il y a une chose que le néophyte que je suis ne comprend pas.
En quoi est-ce un problème d'avoir réussi à trouver deux fichiers qui ont le même hash ? Cela ne permet pas de modifier à volonté un fichier existant tout en laissant son hash inchangé, si ?
En plus, les gens sont parano (et ont raison de l'être parfois).
Une attaque par collision peut être un premier signe d'une faiblesse pour un algorithme, faiblesse qui serait utilisée dans le futur pour une attaque complète. Là c'est au cas par cas, mais on pressent un risque plus fort en général...
Eric P.
Francois Grieu wrote:
- si (azErTy)contient une majuscule) faire ceci sinon cela - si (azerty contient une majuscule) faire ceci sinon cela où azErTy/azerty est un segment du message que l'adversaire peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre, d'où problème si celui qui a construit le message signé avait des intentions délictueuses avant la signature.
A noter que le problème soulevé est pertinent même avec une signature électronique inviolable (donc même avant qu'on ne découvre des failles dans les algos de hash).
Il est en effet très facile de faire afficher un texte différent à un fichier htmljavascript/pdf/word différemment en fonction de n'importe quel paramètre, par exemple l'heure, la machine sur laquelle est lu le fichier...
Donc il est fortement recommandé quand c'est possible de ne signer que des documents sans macro (et de ne faire confiance qu'à des documents signés sans macro). Evidemment pour le cas des programmes informatiques c'est impossible.
Eric
Francois Grieu wrote:
- si (azErTy)contient une majuscule) faire ceci sinon cela
- si (azerty contient une majuscule) faire ceci sinon cela
où azErTy/azerty est un segment du message que l'adversaire
peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre,
d'où problème si celui qui a construit le message signé avait des
intentions délictueuses avant la signature.
A noter que le problème soulevé est pertinent même avec une signature
électronique inviolable (donc même avant qu'on ne découvre des failles
dans les algos de hash).
Il est en effet très facile de faire afficher un texte différent à un
fichier htmljavascript/pdf/word différemment en fonction de n'importe
quel paramètre, par exemple l'heure, la machine sur laquelle est lu le
fichier...
Donc il est fortement recommandé quand c'est possible de ne signer que
des documents sans macro (et de ne faire confiance qu'à des documents
signés sans macro). Evidemment pour le cas des programmes informatiques
c'est impossible.
- si (azErTy)contient une majuscule) faire ceci sinon cela - si (azerty contient une majuscule) faire ceci sinon cela où azErTy/azerty est un segment du message que l'adversaire peut changer sans toucher au hash.
La signature pour un message risque d'être valable pour l'autre, d'où problème si celui qui a construit le message signé avait des intentions délictueuses avant la signature.
A noter que le problème soulevé est pertinent même avec une signature électronique inviolable (donc même avant qu'on ne découvre des failles dans les algos de hash).
Il est en effet très facile de faire afficher un texte différent à un fichier htmljavascript/pdf/word différemment en fonction de n'importe quel paramètre, par exemple l'heure, la machine sur laquelle est lu le fichier...
Donc il est fortement recommandé quand c'est possible de ne signer que des documents sans macro (et de ne faire confiance qu'à des documents signés sans macro). Evidemment pour le cas des programmes informatiques c'est impossible.
Eric
Francois Grieu
"Eric P." dit:
il est fortement recommandé quand c'est possible de ne signer que des documents sans macro (et de ne faire confiance qu'à des documents signés sans macro). Evidemment pour le cas des programmes informatiques c'est impossible.
Oui. Il est aussi conseillé, quand c'est possible, de ne signer que des documents dont on a produit soi-même le contenu; et/ou à défaut, en y ayant mis au début (premier bloc du hash) une valeur imprévisible (aléatoire par exemple). Moyennant cette dernière précaution, il est même possible (si on y est absolument contraint, exemple certificats SSL compatibles avec des équipements déployés) d'utiliser MD5, qui alors n'est vulnérable ni à la force brute, si aux nouvelles attaques. Evidemment, SHA-1 ou RIPEMD-160, c'est mieux.
François Grieu
"Eric P." <ericPASDE@SPAMerixpage.com> dit:
il est fortement recommandé quand c'est possible de ne signer que
des documents sans macro (et de ne faire confiance qu'à des documents
signés sans macro). Evidemment pour le cas des programmes informatiques
c'est impossible.
Oui. Il est aussi conseillé, quand c'est possible, de ne signer que des
documents dont on a produit soi-même le contenu; et/ou à défaut, en y
ayant mis au début (premier bloc du hash) une valeur imprévisible
(aléatoire par exemple). Moyennant cette dernière précaution, il est
même possible (si on y est absolument contraint, exemple certificats SSL
compatibles avec des équipements déployés) d'utiliser MD5, qui alors
n'est vulnérable ni à la force brute, si aux nouvelles attaques.
Evidemment, SHA-1 ou RIPEMD-160, c'est mieux.
il est fortement recommandé quand c'est possible de ne signer que des documents sans macro (et de ne faire confiance qu'à des documents signés sans macro). Evidemment pour le cas des programmes informatiques c'est impossible.
Oui. Il est aussi conseillé, quand c'est possible, de ne signer que des documents dont on a produit soi-même le contenu; et/ou à défaut, en y ayant mis au début (premier bloc du hash) une valeur imprévisible (aléatoire par exemple). Moyennant cette dernière précaution, il est même possible (si on y est absolument contraint, exemple certificats SSL compatibles avec des équipements déployés) d'utiliser MD5, qui alors n'est vulnérable ni à la force brute, si aux nouvelles attaques. Evidemment, SHA-1 ou RIPEMD-160, c'est mieux.
