Pour info, le NIST vient d'annoncer [1] le choix de l'algorithme Keccak
[2] comme lauréat du concours SHA-3, qui visait à choisir un successeur
à la famille de hachages SHA-2.
Je ne connais à peu près rien sur les fonctions de hachage, mais
celle-ci est visiblement originale par sa nature de fonction éponge [3].
Cette originalité a une intérêt particulier, dans la mesure où SHA-3 ne
sera donc pas sujet aux mêmes attaques que ses prédécesseurs.
[3] http://sponge.noekeon.org/
Cette nouvelle fonction de hachage risque malgré tout de mettre du temps
avant de s'implanter vraiment…
[ L'idée étant que SHA-2 est déjà très bon, et n'a pas beaucoup de défauts ]
Tanguy Ortolo
Xavier Roche, 2012-10-03 16:28+0200:
L'annonce n'a pas vraiment déclenché l'enthousiasme. Voir par exemple le "we don't really need a new hash function" (Bruce Schneier)
[ L'idée étant que SHA-2 est déjà très bon, et n'a pas beaucoup de défauts ]
Je crois que cette idée est largement partagée, y compris au sein du NIST. Il est cependant toujours bon d'avoir une solution de secours en cas d'attaque contre SHA-2.
Ceci étant, SHA-1 est lui-même encore largement utilisé, et MD5 également dans une moindre mesure…
L'annonce n'a pas vraiment déclenché l'enthousiasme. Voir par exemple le
"we don't really need a new hash function" (Bruce Schneier)
[ L'idée étant que SHA-2 est déjà très bon, et n'a pas beaucoup de défauts ]
Je crois que cette idée est largement partagée, y compris au sein du
NIST. Il est cependant toujours bon d'avoir une solution de secours en
cas d'attaque contre SHA-2.
Ceci étant, SHA-1 est lui-même encore largement utilisé, et MD5
également dans une moindre mesure…
L'annonce n'a pas vraiment déclenché l'enthousiasme. Voir par exemple le "we don't really need a new hash function" (Bruce Schneier)
[ L'idée étant que SHA-2 est déjà très bon, et n'a pas beaucoup de défauts ]
Je crois que cette idée est largement partagée, y compris au sein du NIST. Il est cependant toujours bon d'avoir une solution de secours en cas d'attaque contre SHA-2.
Ceci étant, SHA-1 est lui-même encore largement utilisé, et MD5 également dans une moindre mesure…
Ben voila ... il n'y a plus qu'a remplacer la fonction SHA-512 par celle la dans notre logiciel de chiffrement par flot et hop ..
http://hmk2012.franceserv.com/
Thomas Pornin
According to Tanguy Ortolo :
Je crois que cette idée est largement partagée, y compris au sein du NIST. Il est cependant toujours bon d'avoir une solution de secours en cas d'attaque contre SHA-2.
En fait c'est bien ça le truc. Initialement, en 2007, avec les trouvailles contre MD5 et SHA-1, le NIST considérait, assez raisonnablement, que SHA-256 et SHA-512 allaient bientôt y passer aussi, et qu'il fallait un remplaçant. Puis, après quelques années, il est apparu que SHA-256 et SHA-512 allaient résister mieux que prévu, et donc que SHA-3 ferait mieux son office en tant que plan de secours, au cas où. Ça a changé les priorités : exit les performances, concentrons-nous sur le candidat le plus différent possible de SHA-256 et SHA-512, afin de limiter les risques d'attaque qui soit valable sur toutes les fonctions à la fois.
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de miracles ! Heureusement, il est très rare que les performances des fonctions de hachage soient un facteur important. Quand on calcule le haché d'un gros fichier, ce qui limite le débit, c'est le disque dur, pas la fonction de hachage (à moins de choisir quelque chose de prodigieusement lent comme Whirlpool).
--Thomas Pornin
According to Tanguy Ortolo <tanguy@ortolo.eu>:
Je crois que cette idée est largement partagée, y compris au sein du
NIST. Il est cependant toujours bon d'avoir une solution de secours en
cas d'attaque contre SHA-2.
En fait c'est bien ça le truc. Initialement, en 2007, avec les
trouvailles contre MD5 et SHA-1, le NIST considérait, assez
raisonnablement, que SHA-256 et SHA-512 allaient bientôt y passer aussi,
et qu'il fallait un remplaçant. Puis, après quelques années, il est
apparu que SHA-256 et SHA-512 allaient résister mieux que prévu, et donc
que SHA-3 ferait mieux son office en tant que plan de secours, au cas
où. Ça a changé les priorités : exit les performances, concentrons-nous
sur le candidat le plus différent possible de SHA-256 et SHA-512, afin
de limiter les risques d'attaque qui soit valable sur toutes les
fonctions à la fois.
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de
miracles ! Heureusement, il est très rare que les performances des
fonctions de hachage soient un facteur important. Quand on calcule le
haché d'un gros fichier, ce qui limite le débit, c'est le disque dur,
pas la fonction de hachage (à moins de choisir quelque chose de
prodigieusement lent comme Whirlpool).
Je crois que cette idée est largement partagée, y compris au sein du NIST. Il est cependant toujours bon d'avoir une solution de secours en cas d'attaque contre SHA-2.
En fait c'est bien ça le truc. Initialement, en 2007, avec les trouvailles contre MD5 et SHA-1, le NIST considérait, assez raisonnablement, que SHA-256 et SHA-512 allaient bientôt y passer aussi, et qu'il fallait un remplaçant. Puis, après quelques années, il est apparu que SHA-256 et SHA-512 allaient résister mieux que prévu, et donc que SHA-3 ferait mieux son office en tant que plan de secours, au cas où. Ça a changé les priorités : exit les performances, concentrons-nous sur le candidat le plus différent possible de SHA-256 et SHA-512, afin de limiter les risques d'attaque qui soit valable sur toutes les fonctions à la fois.
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de miracles ! Heureusement, il est très rare que les performances des fonctions de hachage soient un facteur important. Quand on calcule le haché d'un gros fichier, ce qui limite le débit, c'est le disque dur, pas la fonction de hachage (à moins de choisir quelque chose de prodigieusement lent comme Whirlpool).
--Thomas Pornin
Tanguy Ortolo
Thomas Pornin, 2012-10-04 03:32+0200:
Ça a changé les priorités : exit les performances, concentrons-nous sur le candidat le plus différent possible de SHA-256 et SHA-512, afin de limiter les risques d'attaque qui soit valable sur toutes les fonctions à la fois.
Le lauréat Keccak est cependant réputé pour être rapide, donc je pense que sur ce point-là ils ont dû faire un bno compromis.
Ça a changé les priorités : exit les performances, concentrons-nous
sur le candidat le plus différent possible de SHA-256 et SHA-512, afin
de limiter les risques d'attaque qui soit valable sur toutes les
fonctions à la fois.
Le lauréat Keccak est cependant réputé pour être rapide, donc je pense
que sur ce point-là ils ont dû faire un bno compromis.
Ça a changé les priorités : exit les performances, concentrons-nous sur le candidat le plus différent possible de SHA-256 et SHA-512, afin de limiter les risques d'attaque qui soit valable sur toutes les fonctions à la fois.
Le lauréat Keccak est cependant réputé pour être rapide, donc je pense que sur ce point-là ils ont dû faire un bno compromis.
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de miracles ! Heureusement, il est très rare que les performances des fonctions de hachage soient un facteur important. Quand on calcule le haché d'un gros fichier, ce qui limite le débit, c'est le disque dur, pas la fonction de hachage (à moins de choisir quelque chose de prodigieusement lent comme Whirlpool).
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin <pornin@bolet.org> écrivait :
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de
miracles ! Heureusement, il est très rare que les performances des
fonctions de hachage soient un facteur important. Quand on calcule le
haché d'un gros fichier, ce qui limite le débit, c'est le disque dur,
pas la fonction de hachage (à moins de choisir quelque chose de
prodigieusement lent comme Whirlpool).
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins
un cas où un hash lent (voire très lent) est un avantage :
pour hasher des mots de passe, où l'utilisation normale est de hasher un
mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises
performances vont limiter la faisabilité de la force brute.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ceci rend logique le choix de Keccak. Mais il ne faut pas en espérer de miracles ! Heureusement, il est très rare que les performances des fonctions de hachage soient un facteur important. Quand on calcule le haché d'un gros fichier, ce qui limite le débit, c'est le disque dur, pas la fonction de hachage (à moins de choisir quelque chose de prodigieusement lent comme Whirlpool).
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Tanguy Ortolo
, 2012-10-04 08:56+0200:
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été conçu pour cela. J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins
un cas où un hash lent (voire très lent) est un avantage :
pour hasher des mots de passe, où l'utilisation normale est de hasher un
mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises
performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été conçu
pour cela. J'avais entendu parler il y a quelque temps d'un projet de
hachage à lenteur réglable, d'ailleurs.
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été conçu pour cela. J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
Il y a un pas mal de cas où un paramètre numérique indique le nombre de fois où il faut faire le hash récursivement. Il suffit d'adapter cette valeur en fonction de la vitesse du hash.
Tanguy Ortolo a écrit :
hasher des mots de passe, où l'utilisation normale est de hasher un
mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises
performances vont limiter la faisabilité de la force brute.
J'avais entendu parler il y a quelque temps d'un projet de
hachage à lenteur réglable, d'ailleurs.
Il y a un pas mal de cas où un paramètre numérique indique le nombre de
fois où il faut faire le hash récursivement.
Il suffit d'adapter cette valeur en fonction de la vitesse du hash.
hasher des mots de passe, où l'utilisation normale est de hasher un mot de passe (ou une passe phrase) assez court(e) mais où de mauvaises performances vont limiter la faisabilité de la force brute.
J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
Il y a un pas mal de cas où un paramètre numérique indique le nombre de fois où il faut faire le hash récursivement. Il suffit d'adapter cette valeur en fonction de la vitesse du hash.
Erwann Abalea
Le jeudi 4 octobre 2012 10:44:16 UTC+2, Tanguy Ortolo a écrit :
, 2012-10-04 08:56+0200:
> Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moi ns > un cas où un hash lent (voire très lent) est un avantage : > pour hasher des mots de passe, où l'utilisation normale est de hasher un > mot de passe (ou une passe phrase) assez court(e) mais où de mauvaise s > performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été con çu pour cela. J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
bcrypt, et maintenant scrypt. Le premier peut être paramétré pour prendre du temps, comme PBKDF2, l e second peut aussi être paramétré pour consommer de la RAM, ressourc e plutôt rare sur un FPGA ou un ASIC.
Le jeudi 4 octobre 2012 10:44:16 UTC+2, Tanguy Ortolo a écrit :
erwan@rail.eu.org, 2012-10-04 08:56+0200:
> Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moi ns
> un cas où un hash lent (voire très lent) est un avantage :
> pour hasher des mots de passe, où l'utilisation normale est de hasher un
> mot de passe (ou une passe phrase) assez court(e) mais où de mauvaise s
> performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été con çu
pour cela. J'avais entendu parler il y a quelque temps d'un projet de
hachage à lenteur réglable, d'ailleurs.
bcrypt, et maintenant scrypt.
Le premier peut être paramétré pour prendre du temps, comme PBKDF2, l e second peut aussi être paramétré pour consommer de la RAM, ressourc e plutôt rare sur un FPGA ou un ASIC.
Le jeudi 4 octobre 2012 10:44:16 UTC+2, Tanguy Ortolo a écrit :
, 2012-10-04 08:56+0200:
> Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moi ns > un cas où un hash lent (voire très lent) est un avantage : > pour hasher des mots de passe, où l'utilisation normale est de hasher un > mot de passe (ou une passe phrase) assez court(e) mais où de mauvaise s > performances vont limiter la faisabilité de la force brute.
Effectivement, et il me semble d'ailleurs que crypt() avait été con çu pour cela. J'avais entendu parler il y a quelque temps d'un projet de hachage à lenteur réglable, d'ailleurs.
bcrypt, et maintenant scrypt. Le premier peut être paramétré pour prendre du temps, comme PBKDF2, l e second peut aussi être paramétré pour consommer de la RAM, ressourc e plutôt rare sur un FPGA ou un ASIC.
Thomas Pornin
According to :
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe
Pour ça, il faut quelque chose de vraiment lent, beaucoup plus lent que Whirlpool. En fait, on veut un système avec des itérations qui permette de rendre le hachage aussi lent que possible, suivant le budget CPU qu'on a. À partir du moment où on itère, on peut prendre la fonction de base qu'on veut, même une "rapide".
Il y a grosso-modo trois constructions "sérieuses" pour ce travail : PBKDF2, bcrypt et scrypt.
PBKDF2 vient de PKCS#5 (RFC 2898) et utilise une foncton de hachage "standard" comme SHA-256. On fait quelques milliers (ou millions) d'itérations, et hop. Le NIST aime bien PBKDF2 (le NIST ne dit rien sur les deux autres).
Bcrypt est un dérivé de Blowfish, en augmentant (fortement et de façon configurable) le nombre d'itérations dans le key schedule. Il est assez répandu (il date de 1999 et OpenBSD s'en sert par défaut). Un avantage de bcrypt, c'est qu'il travaille avec des accès pseudo-aléatoires, en lecture et en écriture, dans un tableau de 4 Ko : un PC sait bien faire ça, mais les GPU ont plus de mal. C'est un bienfait, parce que dans le cas qui nous intéresse, le défendeur et l'attaquant font la course au CPU (on augmente le coût du hachage autant qu'on peut, afin de ralentir l'attaquant aussi). Or, si le défendeur est un serveur qui a autre chose à faire que vérifier des mots de passe, l'attaquant peut se spécialiser, paralléliser, et investir dans un gros GPU. Avec 1000$ de GPU, l'attaquant peut essayer beaucoup plus de mots de passe par seconde qu'avec 1000$ de CPU, _si_ le hachage utilise PBKDF2 avec SHA-256 ; mais ce n'est pas le cas avec bcrypt.
Scrypt est un schéma récent (2009) qui travaille dans cette direction. Il utilise une fonction de hachage standard, mais avec un tableau en RAM qui peut être gros (genre 2 Mo). Non seulement les GPU n'aiment pas, mais ça gène aussi les attaquants qui ont des FPGA (les FPGA Xilinx Virtex ont des blocs de RAM inclus dans le circuit, ils peuvent manger du bcrypt au petit déjeûner).
En bref, PBKDF2 c'est bien, bcrypt c'est mieux, et scrypt sera encore mieux quand on l'aura testé assez longtemps pour se dire qu'il est probablement robuste.
--Thomas Pornin
According to <erwan@rail.eu.org>:
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins
un cas où un hash lent (voire très lent) est un avantage :
pour hasher des mots de passe
Pour ça, il faut quelque chose de vraiment lent, beaucoup plus lent
que Whirlpool. En fait, on veut un système avec des itérations qui
permette de rendre le hachage aussi lent que possible, suivant le
budget CPU qu'on a. À partir du moment où on itère, on peut prendre
la fonction de base qu'on veut, même une "rapide".
Il y a grosso-modo trois constructions "sérieuses" pour ce travail :
PBKDF2, bcrypt et scrypt.
PBKDF2 vient de PKCS#5 (RFC 2898) et utilise une foncton de hachage
"standard" comme SHA-256. On fait quelques milliers (ou millions)
d'itérations, et hop. Le NIST aime bien PBKDF2 (le NIST ne dit rien
sur les deux autres).
Bcrypt est un dérivé de Blowfish, en augmentant (fortement et de façon
configurable) le nombre d'itérations dans le key schedule. Il est assez
répandu (il date de 1999 et OpenBSD s'en sert par défaut). Un avantage
de bcrypt, c'est qu'il travaille avec des accès pseudo-aléatoires, en
lecture et en écriture, dans un tableau de 4 Ko : un PC sait bien faire
ça, mais les GPU ont plus de mal. C'est un bienfait, parce que dans le
cas qui nous intéresse, le défendeur et l'attaquant font la course au
CPU (on augmente le coût du hachage autant qu'on peut, afin de ralentir
l'attaquant aussi). Or, si le défendeur est un serveur qui a autre chose
à faire que vérifier des mots de passe, l'attaquant peut se spécialiser,
paralléliser, et investir dans un gros GPU. Avec 1000$ de GPU, l'attaquant
peut essayer beaucoup plus de mots de passe par seconde qu'avec 1000$ de
CPU, _si_ le hachage utilise PBKDF2 avec SHA-256 ; mais ce n'est pas le
cas avec bcrypt.
Scrypt est un schéma récent (2009) qui travaille dans cette direction.
Il utilise une fonction de hachage standard, mais avec un tableau en RAM
qui peut être gros (genre 2 Mo). Non seulement les GPU n'aiment pas,
mais ça gène aussi les attaquants qui ont des FPGA (les FPGA Xilinx
Virtex ont des blocs de RAM inclus dans le circuit, ils peuvent manger
du bcrypt au petit déjeûner).
En bref, PBKDF2 c'est bien, bcrypt c'est mieux, et scrypt sera encore mieux
quand on l'aura testé assez longtemps pour se dire qu'il est probablement
robuste.
Je ne connais pas Whirlpool, mais c'est intéressant car il y a au moins un cas où un hash lent (voire très lent) est un avantage : pour hasher des mots de passe
Pour ça, il faut quelque chose de vraiment lent, beaucoup plus lent que Whirlpool. En fait, on veut un système avec des itérations qui permette de rendre le hachage aussi lent que possible, suivant le budget CPU qu'on a. À partir du moment où on itère, on peut prendre la fonction de base qu'on veut, même une "rapide".
Il y a grosso-modo trois constructions "sérieuses" pour ce travail : PBKDF2, bcrypt et scrypt.
PBKDF2 vient de PKCS#5 (RFC 2898) et utilise une foncton de hachage "standard" comme SHA-256. On fait quelques milliers (ou millions) d'itérations, et hop. Le NIST aime bien PBKDF2 (le NIST ne dit rien sur les deux autres).
Bcrypt est un dérivé de Blowfish, en augmentant (fortement et de façon configurable) le nombre d'itérations dans le key schedule. Il est assez répandu (il date de 1999 et OpenBSD s'en sert par défaut). Un avantage de bcrypt, c'est qu'il travaille avec des accès pseudo-aléatoires, en lecture et en écriture, dans un tableau de 4 Ko : un PC sait bien faire ça, mais les GPU ont plus de mal. C'est un bienfait, parce que dans le cas qui nous intéresse, le défendeur et l'attaquant font la course au CPU (on augmente le coût du hachage autant qu'on peut, afin de ralentir l'attaquant aussi). Or, si le défendeur est un serveur qui a autre chose à faire que vérifier des mots de passe, l'attaquant peut se spécialiser, paralléliser, et investir dans un gros GPU. Avec 1000$ de GPU, l'attaquant peut essayer beaucoup plus de mots de passe par seconde qu'avec 1000$ de CPU, _si_ le hachage utilise PBKDF2 avec SHA-256 ; mais ce n'est pas le cas avec bcrypt.
Scrypt est un schéma récent (2009) qui travaille dans cette direction. Il utilise une fonction de hachage standard, mais avec un tableau en RAM qui peut être gros (genre 2 Mo). Non seulement les GPU n'aiment pas, mais ça gène aussi les attaquants qui ont des FPGA (les FPGA Xilinx Virtex ont des blocs de RAM inclus dans le circuit, ils peuvent manger du bcrypt au petit déjeûner).
En bref, PBKDF2 c'est bien, bcrypt c'est mieux, et scrypt sera encore mieux quand on l'aura testé assez longtemps pour se dire qu'il est probablement robuste.
