Depuis quelques années déjà, on recommande de passer à SHA-2 (SHA-256 ou SHA-512) pour tous nouveaux usages.
Quelle est la considération de RIPEMD-160? -- Kevin
Paul Gaborit
À (at) Tue, 20 Jan 2009 17:42:02 +0100, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
À (at) Tue, 20 Jan 2009 15:22:08 +0100, Erwan David écrivait (wrote):
Thomas Pornin écrivait :
C'est du bon gros calcul distribué avec un coût théorique en O(2^63),
euh, O(cste)=O(1), non ?
O(cste) est bien du même ordre que O(1) mais pas strictement égal.
Effectivement le coût théorique d'une recherche de collision sur SHA-1 (par un algorithme donné) est bien une constante... mais c'est une constante *énorme* (2^63). ;-)
Oui, mais O(f(n)) signifie que lim(temps(programme)/f(n)) quand n tend vers l'infini est une constante non nulle... Donc O(cste) signifie (comme O(1)) que le programme s'exécute en temps constant, et ne donne aucune information supplémentaire.
Dans l'absolu, avec une telle définition de O(.), on ne sait absolument rien de l'algorithme (ou du programme qui en découle) puisqu'on n'est jamais dans le cas où n est infini (et donc dans le cas où le rapport est constant).
Mais, d'un point de vue pratique, lorsqu'on mesure la complexité d'un algorithme, on se base sur le nombre d'opérations élémentaires nécessaires et c'est cette mesure (ou une bonne approximation) qui définit f(n). Ici, mis à part Thomas, personne ne peut dire à quelles opérations élémentaires faisait référence le 2^63. Par contre, nous sommes tous capables de déterminer l'opération élémentaire la plus rapide réalisable par le processeur le plus rapide à ce jour. On peut donc en déduire une borne minimale du temps d'exécution. C'est largement suffisant pour l'exposé...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 20 Jan 2009 17:42:02 +0100,
Erwan David <erwan@rail.eu.org> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
À (at) Tue, 20 Jan 2009 15:22:08 +0100,
Erwan David <erwan@rail.eu.org> écrivait (wrote):
Thomas Pornin <pornin@bolet.org> écrivait :
C'est du bon gros calcul distribué avec un coût théorique en O(2^63),
euh, O(cste)=O(1), non ?
O(cste) est bien du même ordre que O(1) mais pas strictement
égal.
Effectivement le coût théorique d'une recherche de collision sur SHA-1
(par un algorithme donné) est bien une constante... mais c'est une
constante *énorme* (2^63). ;-)
Oui, mais O(f(n)) signifie que lim(temps(programme)/f(n)) quand n tend
vers l'infini est une constante non nulle... Donc O(cste) signifie
(comme O(1)) que le programme s'exécute en temps constant, et ne donne
aucune information supplémentaire.
Dans l'absolu, avec une telle définition de O(.), on ne sait
absolument rien de l'algorithme (ou du programme qui en découle)
puisqu'on n'est jamais dans le cas où n est infini (et donc dans le
cas où le rapport est constant).
Mais, d'un point de vue pratique, lorsqu'on mesure la complexité d'un
algorithme, on se base sur le nombre d'opérations élémentaires
nécessaires et c'est cette mesure (ou une bonne approximation) qui
définit f(n). Ici, mis à part Thomas, personne ne peut dire à quelles
opérations élémentaires faisait référence le 2^63. Par contre, nous
sommes tous capables de déterminer l'opération élémentaire la plus
rapide réalisable par le processeur le plus rapide à ce jour. On peut
donc en déduire une borne minimale du temps d'exécution. C'est
largement suffisant pour l'exposé...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 20 Jan 2009 17:42:02 +0100, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
À (at) Tue, 20 Jan 2009 15:22:08 +0100, Erwan David écrivait (wrote):
Thomas Pornin écrivait :
C'est du bon gros calcul distribué avec un coût théorique en O(2^63),
euh, O(cste)=O(1), non ?
O(cste) est bien du même ordre que O(1) mais pas strictement égal.
Effectivement le coût théorique d'une recherche de collision sur SHA-1 (par un algorithme donné) est bien une constante... mais c'est une constante *énorme* (2^63). ;-)
Oui, mais O(f(n)) signifie que lim(temps(programme)/f(n)) quand n tend vers l'infini est une constante non nulle... Donc O(cste) signifie (comme O(1)) que le programme s'exécute en temps constant, et ne donne aucune information supplémentaire.
Dans l'absolu, avec une telle définition de O(.), on ne sait absolument rien de l'algorithme (ou du programme qui en découle) puisqu'on n'est jamais dans le cas où n est infini (et donc dans le cas où le rapport est constant).
Mais, d'un point de vue pratique, lorsqu'on mesure la complexité d'un algorithme, on se base sur le nombre d'opérations élémentaires nécessaires et c'est cette mesure (ou une bonne approximation) qui définit f(n). Ici, mis à part Thomas, personne ne peut dire à quelles opérations élémentaires faisait référence le 2^63. Par contre, nous sommes tous capables de déterminer l'opération élémentaire la plus rapide réalisable par le processeur le plus rapide à ce jour. On peut donc en déduire une borne minimale du temps d'exécution. C'est largement suffisant pour l'exposé...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
J
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit :
Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet fixé ... parce que la cardinalité de l'ensemble des sorties d'une fonction de hachage est plutôt énorme.
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
a +.
-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit :
Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie
présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet
fixé ... parce que la cardinalité de l'ensemble des sorties d'une
fonction de hachage est plutôt énorme.
Et l'émir utiliserait sans doute la techniques des rainbows tables pour
optimiser le calcul :)
a +.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit :
Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet fixé ... parce que la cardinalité de l'ensemble des sorties d'une fonction de hachage est plutôt énorme.
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
a +.
-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Thomas Pornin
According to Erwan David :
euh, O(cste)=O(1), non ?
Certes, la notation O(.) est abusive ici, puisqu'il n'y a pas de paramètre variant. Mais c'est l'usage courant. Plus précisément, pour les attaques sur la fonction de hachage, on mesure le "coût CPU" en équivalent invocations de la fonctions, et on utilise le "O" pour l'indiquer. Donc un coût CPU similaire à celui du hachage par SHA-1 de 2^63 messages courts (dans le cas de SHA-1 sur mon PC -- un Intel Core2 quad core Q6600, le hachage d'un message court par SHA-1 prend 488 cycles d'horloge, pour un coeur).
(Après tout, il n'y a que 26 lettres dans l'alphabet, donc c'est attendu qu'il y ait un peu de surcharge de notation.)
--Thomas Pornin
According to Erwan David <erwan@rail.eu.org>:
euh, O(cste)=O(1), non ?
Certes, la notation O(.) est abusive ici, puisqu'il n'y a pas de
paramètre variant. Mais c'est l'usage courant. Plus précisément, pour
les attaques sur la fonction de hachage, on mesure le "coût CPU" en
équivalent invocations de la fonctions, et on utilise le "O" pour
l'indiquer. Donc un coût CPU similaire à celui du hachage par SHA-1 de
2^63 messages courts (dans le cas de SHA-1 sur mon PC -- un Intel Core2
quad core Q6600, le hachage d'un message court par SHA-1 prend 488
cycles d'horloge, pour un coeur).
(Après tout, il n'y a que 26 lettres dans l'alphabet, donc c'est
attendu qu'il y ait un peu de surcharge de notation.)
Certes, la notation O(.) est abusive ici, puisqu'il n'y a pas de paramètre variant. Mais c'est l'usage courant. Plus précisément, pour les attaques sur la fonction de hachage, on mesure le "coût CPU" en équivalent invocations de la fonctions, et on utilise le "O" pour l'indiquer. Donc un coût CPU similaire à celui du hachage par SHA-1 de 2^63 messages courts (dans le cas de SHA-1 sur mon PC -- un Intel Core2 quad core Q6600, le hachage d'un message court par SHA-1 prend 488 cycles d'horloge, pour un coeur).
(Après tout, il n'y a que 26 lettres dans l'alphabet, donc c'est attendu qu'il y ait un peu de surcharge de notation.)
--Thomas Pornin
Thomas Pornin
According to Jérôme Benoit :
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit : > Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie > présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet fixée ... parce que la cardinalité de l'ensemble des sorties d'une fonction de hachage est plutôt énorme.
Ben, c'est ce que je dis. La sortie de MD5 fait 128 bits, et on discute de la surjectivité (i.e. est-ce que toutes les suites de 128 bits peuvent être obtenues ?). La cardinalité de l'ensemble des suites de 128 bits, c'est le nombre de combinaisons de 128 valeurs 0 ou 1, il y en a "deux à la puissance 128", ce que je note 2^128. En décimal, ça fait 340282366920938463463374607431768211456 (et oui, c'est beaucoup trop gros pour être énuméré, pétro-dollars ou pas).
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de diverses entrées, avec quelques finasseries pour optimiser des attaques par dictionnaire quand il y a eu hachage de mot de passe avec ajout d'une graine. Ça n'a pas de pertinence pour le problème théorique dont on parle ici.
--Thomas Pornin
According to Jérôme Benoit <jerome.benoit@grenouille.com>:
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit :
> Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie
> présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet
fixée ... parce que la cardinalité de l'ensemble des sorties d'une
fonction de hachage est plutôt énorme.
Ben, c'est ce que je dis. La sortie de MD5 fait 128 bits, et on discute
de la surjectivité (i.e. est-ce que toutes les suites de 128 bits
peuvent être obtenues ?). La cardinalité de l'ensemble des suites de
128 bits, c'est le nombre de combinaisons de 128 valeurs 0 ou 1, il
y en a "deux à la puissance 128", ce que je note 2^128. En décimal,
ça fait 340282366920938463463374607431768211456 (et oui, c'est beaucoup
trop gros pour être énuméré, pétro-dollars ou pas).
Et l'émir utiliserait sans doute la techniques des rainbows tables pour
optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de
diverses entrées, avec quelques finasseries pour optimiser des attaques
par dictionnaire quand il y a eu hachage de mot de passe avec ajout
d'une graine. Ça n'a pas de pertinence pour le problème théorique dont
on parle ici.
Le Mon, 19 Jan 2009 01:38:56 +0000, Thomas Pornin a écrit : > Par ailleurs il faudra passer beaucoup de fois. Si l'ensemble de sortie > présumé est de taille N (ici, N = 2^128),
Tu veux dire que les éléments de l'ensemble ont une longueur en octet fixée ... parce que la cardinalité de l'ensemble des sorties d'une fonction de hachage est plutôt énorme.
Ben, c'est ce que je dis. La sortie de MD5 fait 128 bits, et on discute de la surjectivité (i.e. est-ce que toutes les suites de 128 bits peuvent être obtenues ?). La cardinalité de l'ensemble des suites de 128 bits, c'est le nombre de combinaisons de 128 valeurs 0 ou 1, il y en a "deux à la puissance 128", ce que je note 2^128. En décimal, ça fait 340282366920938463463374607431768211456 (et oui, c'est beaucoup trop gros pour être énuméré, pétro-dollars ou pas).
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de diverses entrées, avec quelques finasseries pour optimiser des attaques par dictionnaire quand il y a eu hachage de mot de passe avec ajout d'une graine. Ça n'a pas de pertinence pour le problème théorique dont on parle ici.
--Thomas Pornin
J
Le Wed, 21 Jan 2009 02:00:24 +0000, Thomas Pornin a écrit :
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de diverses entrées, avec quelques finasseries pour optimiser des attaques par dictionnaire quand il y a eu hachage de mot de passe avec ajout d'une graine. Ça n'a pas de pertinence pour le problème théorique dont on parle ici.
Ben tu cherches à savoir si chaque hash md5 a un antécédent au moins ou pas ?
Parce si par un heureux hasard tu construis une méthode qui permette d'optimiser la recherche d'un antécédent pour chaque hash md5 en partant de l'entrée, me semble que tu tapes pas trop loin de ton objectif.
Certes, l'ensemble en entrée est infini et tu connais pas tous les hash md5 possibles pour savoir quand tu auras fini, mais bon, ça fait déjà une base de travail plus réaliste avec la puissance de calcul actuelle.
a +.
-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Wed, 21 Jan 2009 02:00:24 +0000, Thomas Pornin a écrit :
Et l'émir utiliserait sans doute la techniques des rainbows tables pour
optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de
diverses entrées, avec quelques finasseries pour optimiser des attaques
par dictionnaire quand il y a eu hachage de mot de passe avec ajout
d'une graine. Ça n'a pas de pertinence pour le problème théorique dont
on parle ici.
Ben tu cherches à savoir si chaque hash md5 a un antécédent au moins ou
pas ?
Parce si par un heureux hasard tu construis une méthode qui permette
d'optimiser la recherche d'un antécédent pour chaque hash md5 en partant
de l'entrée, me semble que tu tapes pas trop loin de ton objectif.
Certes, l'ensemble en entrée est infini et tu connais pas tous les hash
md5 possibles pour savoir quand tu auras fini, mais bon, ça fait déjà une
base de travail plus réaliste avec la puissance de calcul actuelle.
a +.
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Le Wed, 21 Jan 2009 02:00:24 +0000, Thomas Pornin a écrit :
Et l'émir utiliserait sans doute la techniques des rainbows tables pour optimiser le calcul :)
Les "rainbow tables" ne sont que des tables précalculées de hachage de diverses entrées, avec quelques finasseries pour optimiser des attaques par dictionnaire quand il y a eu hachage de mot de passe avec ajout d'une graine. Ça n'a pas de pertinence pour le problème théorique dont on parle ici.
Ben tu cherches à savoir si chaque hash md5 a un antécédent au moins ou pas ?
Parce si par un heureux hasard tu construis une méthode qui permette d'optimiser la recherche d'un antécédent pour chaque hash md5 en partant de l'entrée, me semble que tu tapes pas trop loin de ton objectif.
Certes, l'ensemble en entrée est infini et tu connais pas tous les hash md5 possibles pour savoir quand tu auras fini, mais bon, ça fait déjà une base de travail plus réaliste avec la puissance de calcul actuelle.
a +.
-- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Jean-Marc Desperrier
Kevin Denis a écrit :
Le 20-01-2009, Thomas Pornin a écrit :
> > Depuis quelques années déjà, on recommande de passer à SHA-2 (SHA-256 ou > SHA-512) pour tous nouveaux usages. >
Quelle est la considération de RIPEMD-160?
RIPEMD-160 est un bon algorithme, solide, largement implémenté, et malheureusement qui souffre beaucoup du fait qu'il n'intéresse pas assez les gens pour que l'on sache si le manque d'attaque contre lui provient de sa solidité ou du fait que pas assez de monde a essayé de le casser.
Tout ce qu'on peut dire est qu'apparement les attaques sur le SHA-1/MD-5 ne sont pas très faciles à transposer sur RIPEMD-160, puisqu'elles l'ont été à RIPEMD, mais pas à RIPEMD-160.
Peut-être est-ce le poids du NIST qui fait que suite aux attaques de 2004 sur le MD5/SHA-1, on a beaucoup plus envisagé comme remplaçant SHA-256 que de reconsidérer RIPEMD-160. Peut-être aussi un peu que Dobbertin s'il n'était pas décédé en 2006 "des suites d'une longue maladie" aurait eu l'occasion de mettre un peu plus son poids dans la balance pour défendre son invention.
En tout cas maintenant, les jeux sont faits, l'avenir appartient plutôt aux fonctions qui concourent pour la sélection de l'algorithme SHA-3 : http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html
Kevin Denis a écrit :
Le 20-01-2009, Thomas Pornin<pornin@bolet.org> a écrit :
>
> Depuis quelques années déjà, on recommande de passer à SHA-2 (SHA-256 ou
> SHA-512) pour tous nouveaux usages.
>
Quelle est la considération de RIPEMD-160?
RIPEMD-160 est un bon algorithme, solide, largement implémenté, et
malheureusement qui souffre beaucoup du fait qu'il n'intéresse pas assez
les gens pour que l'on sache si le manque d'attaque contre lui provient
de sa solidité ou du fait que pas assez de monde a essayé de le casser.
Tout ce qu'on peut dire est qu'apparement les attaques sur le SHA-1/MD-5
ne sont pas très faciles à transposer sur RIPEMD-160, puisqu'elles l'ont
été à RIPEMD, mais pas à RIPEMD-160.
Peut-être est-ce le poids du NIST qui fait que suite aux attaques de
2004 sur le MD5/SHA-1, on a beaucoup plus envisagé comme remplaçant
SHA-256 que de reconsidérer RIPEMD-160. Peut-être aussi un peu que
Dobbertin s'il n'était pas décédé en 2006 "des suites d'une longue
maladie" aurait eu l'occasion de mettre un peu plus son poids dans la
balance pour défendre son invention.
En tout cas maintenant, les jeux sont faits, l'avenir appartient plutôt
aux fonctions qui concourent pour la sélection de l'algorithme SHA-3 :
http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html
> > Depuis quelques années déjà, on recommande de passer à SHA-2 (SHA-256 ou > SHA-512) pour tous nouveaux usages. >
Quelle est la considération de RIPEMD-160?
RIPEMD-160 est un bon algorithme, solide, largement implémenté, et malheureusement qui souffre beaucoup du fait qu'il n'intéresse pas assez les gens pour que l'on sache si le manque d'attaque contre lui provient de sa solidité ou du fait que pas assez de monde a essayé de le casser.
Tout ce qu'on peut dire est qu'apparement les attaques sur le SHA-1/MD-5 ne sont pas très faciles à transposer sur RIPEMD-160, puisqu'elles l'ont été à RIPEMD, mais pas à RIPEMD-160.
Peut-être est-ce le poids du NIST qui fait que suite aux attaques de 2004 sur le MD5/SHA-1, on a beaucoup plus envisagé comme remplaçant SHA-256 que de reconsidérer RIPEMD-160. Peut-être aussi un peu que Dobbertin s'il n'était pas décédé en 2006 "des suites d'une longue maladie" aurait eu l'occasion de mettre un peu plus son poids dans la balance pour défendre son invention.
En tout cas maintenant, les jeux sont faits, l'avenir appartient plutôt aux fonctions qui concourent pour la sélection de l'algorithme SHA-3 : http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/submissions_rnd1.html
Thomas Pornin
According to Kevin Denis :
Quelle est la considération de RIPEMD-160?
Semi méfiance. RIPEMD-160 est une réparation (en fait une modification assez importante) de RIPEMD, pour lequel des collisions ont été trouvées. RIPEMD était lui-même une fonction reprenant des éléments de MD4. D'un certain point de vue, on pourrait dire que MD5 et RIPEMD sont frères, tous deux "réparant" MD4 (mais selon deux voies différentes) et tous deux cassés. Chacun a eu un descendant, qui le "répare" à nouveau et amène la sortie à 160 bits ; ce sont respectivement SHA-1 et RIPEMD-160. Donc, selon cette vision un peu simpliste, RIPEMD-160 serait assez équivalent à SHA-1, lequel est maintenant entouré d'une certaine méfiance. L'absence d'attaque connue sur RIPEMD-160 serait plutôt dûe à un manque d'intérêt des cryptanalystes, la fonction n'étant qu'assez peu utilisée (elle rentre dans OpenPGP mais elle n'est pas utilisée pour SSL ni dans les standards X.509 et dérivés, donc casser RIPEMD-160 n'a pas du tout l'impact médiatique qu'un cassage de SHA-1 pourrait avoir).
Par ailleurs, RIPEMD-160 est plus lent que SHA-1, pour la même taille de sortie, donc quelque part, "on n'en a pas pour son argent".
De toutes façons, la sortie de 160 bits impose une limite théorique de robustesse à 2^80 (pour la résistance aux collisions), que la fonction soit parfaite ou pas, et l'augmentation continue de puissance machine amenuise la marge de sécurité à ce niveau. Après tout, un calcul en 2^64 étapes comparables (une recherche de clé RC5) a été mené à terme (il y a déjà quelques années) et si la fameuse loi de Moore se maintient, les 2^80 devrait être faisable avant l'an 2020 (en 1997, Gordon Moore lui-même a estimé que sa fameuse loi devrait continuer à être valide pour une vingtaine d'années, donc 2017).
--Thomas Pornin
According to Kevin Denis <kevin@alinto.comNOSPAM>:
Quelle est la considération de RIPEMD-160?
Semi méfiance. RIPEMD-160 est une réparation (en fait une modification
assez importante) de RIPEMD, pour lequel des collisions ont été
trouvées. RIPEMD était lui-même une fonction reprenant des éléments de
MD4. D'un certain point de vue, on pourrait dire que MD5 et RIPEMD sont
frères, tous deux "réparant" MD4 (mais selon deux voies différentes) et
tous deux cassés. Chacun a eu un descendant, qui le "répare" à nouveau
et amène la sortie à 160 bits ; ce sont respectivement SHA-1 et
RIPEMD-160. Donc, selon cette vision un peu simpliste, RIPEMD-160 serait
assez équivalent à SHA-1, lequel est maintenant entouré d'une certaine
méfiance. L'absence d'attaque connue sur RIPEMD-160 serait plutôt dûe à
un manque d'intérêt des cryptanalystes, la fonction n'étant qu'assez peu
utilisée (elle rentre dans OpenPGP mais elle n'est pas utilisée pour SSL
ni dans les standards X.509 et dérivés, donc casser RIPEMD-160 n'a pas
du tout l'impact médiatique qu'un cassage de SHA-1 pourrait avoir).
Par ailleurs, RIPEMD-160 est plus lent que SHA-1, pour la même taille
de sortie, donc quelque part, "on n'en a pas pour son argent".
De toutes façons, la sortie de 160 bits impose une limite théorique de
robustesse à 2^80 (pour la résistance aux collisions), que la fonction
soit parfaite ou pas, et l'augmentation continue de puissance machine
amenuise la marge de sécurité à ce niveau. Après tout, un calcul en 2^64
étapes comparables (une recherche de clé RC5) a été mené à terme (il y a
déjà quelques années) et si la fameuse loi de Moore se maintient, les
2^80 devrait être faisable avant l'an 2020 (en 1997, Gordon Moore
lui-même a estimé que sa fameuse loi devrait continuer à être valide
pour une vingtaine d'années, donc 2017).
Semi méfiance. RIPEMD-160 est une réparation (en fait une modification assez importante) de RIPEMD, pour lequel des collisions ont été trouvées. RIPEMD était lui-même une fonction reprenant des éléments de MD4. D'un certain point de vue, on pourrait dire que MD5 et RIPEMD sont frères, tous deux "réparant" MD4 (mais selon deux voies différentes) et tous deux cassés. Chacun a eu un descendant, qui le "répare" à nouveau et amène la sortie à 160 bits ; ce sont respectivement SHA-1 et RIPEMD-160. Donc, selon cette vision un peu simpliste, RIPEMD-160 serait assez équivalent à SHA-1, lequel est maintenant entouré d'une certaine méfiance. L'absence d'attaque connue sur RIPEMD-160 serait plutôt dûe à un manque d'intérêt des cryptanalystes, la fonction n'étant qu'assez peu utilisée (elle rentre dans OpenPGP mais elle n'est pas utilisée pour SSL ni dans les standards X.509 et dérivés, donc casser RIPEMD-160 n'a pas du tout l'impact médiatique qu'un cassage de SHA-1 pourrait avoir).
Par ailleurs, RIPEMD-160 est plus lent que SHA-1, pour la même taille de sortie, donc quelque part, "on n'en a pas pour son argent".
De toutes façons, la sortie de 160 bits impose une limite théorique de robustesse à 2^80 (pour la résistance aux collisions), que la fonction soit parfaite ou pas, et l'augmentation continue de puissance machine amenuise la marge de sécurité à ce niveau. Après tout, un calcul en 2^64 étapes comparables (une recherche de clé RC5) a été mené à terme (il y a déjà quelques années) et si la fameuse loi de Moore se maintient, les 2^80 devrait être faisable avant l'an 2020 (en 1997, Gordon Moore lui-même a estimé que sa fameuse loi devrait continuer à être valide pour une vingtaine d'années, donc 2017).
