SHA-3

Le
Tanguy Ortolo
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.

[1] http://www.nist.gov/itl/csd/sha-100212.cfm
[2] http://keccak.noekeon.org/

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…


--
  ____   Tanguy Ortolo
 /_   ______________
((_)   _ .--^^^-^-'
 ____/ `' urn:pgp:240BBA15B694DD00E38030D8D6EFA6AC4B10D847:
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Xavier Roche
Le #24835142
On 10/03/2012 03:07 PM, Tanguy Ortolo wrote:
Cette nouvelle fonction de hachage risque malgré tout de mettre du temps
avant de s'implanter vraiment…



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 ]
Tanguy Ortolo
Le #24835382
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…

--
  ____   Tanguy Ortolo
 /_   ______________
((_)   _ .--^---^^-^-'
 ____/ `' urn:pgp:240BBA15B694DD00E38030D8D6EFA6AC4B10D847:
Philippe Lheureux
Le #24835792
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
Le #24836682
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
Tanguy Ortolo
Le #24836762
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.

--
  ____   Tanguy Ortolo
 /_   ______________
((_)   _ .--^---^^-^-'
 ____/ `' urn:pgp:240BBA15B694DD00E38030D8D6EFA6AC4B10D847:
erwan
Le #24836842
Thomas Pornin

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
Le #24837042
, 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.

--
  ____   Tanguy Ortolo
 /_   ______________
((_)   _ .--^---^^-^-'
 ____/ `' urn:pgp:240BBA15B694DD00E38030D8D6EFA6AC4B10D847:
Jean-Marc Desperrier
Le #24837832
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.
Erwann Abalea
Le #24837872
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
Le #24840132
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
Publicité
Poster une réponse
Anonyme