utiliser HMAC-SHA512

Le
Yo
Bonjour,

Je souhaite utiliser l'algorithme HMAC-SHA512 pour crypter les mots de
passe de mon application en utilisant une clef qui soit spécifique à la
société où je travaille.

Toutefois, je n'arrive pas à trouver d'informations sur les tailles min
et max de la clef, ni sur la façon de la générer (s'agit il d'octets
choisis aléatoirement) ?

Merci de vos conseils.
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
Francois Grieu
Le #22798431
Le 15/11/2010 11:18, Yo a écrit :
Je souhaite utiliser l'algorithme HMAC-SHA512 pour crypter les mots de
passe de mon application en utilisant une clef qui soit spécifique à la
société où je travaille.

Toutefois, je n'arrive pas à trouver d'informations sur les tailles min
et max de la clef, ni sur la façon de la générer (s'agit il d'octets
choisis aléatoirement) ?



Par définition de HMAC, la taille de clé est contrainte à être au plus
la taille de bloc du hash, donc 1024 bits = 128 octets pour HMAC-SHA512.

La taille de clé doit être suffisante pour résister à l'énumération par
un adversaire. Un CPU moderne traite de l'ordre de 2^24 blocs SHA-512
par seconde et par coeur, donc pour un quadricoeur et compte tenu qu'il
faut traiter 4 blocs par HMAC-SHA512, 2^24 HMAC-SHA512 par CPU et par
seconde. Il y a un peu moins de 2^25 secondes par an. La puissance de
calcul à coût constant double tout les 18 mois environ (les estimations
varient). Si on considère un adversaire disposant de ressources de
calcul correspondant à 1000 CPU.an aujourd'hui (2^10), se projette à 15
ans (2^(15*12/18) = 2^10), et souhaite qu'il y ait une chance sur 1000
que la clé soit découverte (2^10), il faut une clé de 24+25+10+10+10 79 bits d'entropie.

Si on prend une clé constituée d'octets aléatoires, il est prudent de
mettre au moins 10 octets; mais 32 ce n'est guère plus cher.

Si la clé doit être du texte, il faut prévoir beaucoup plus, disons 40
caractères au moins; mais 128 ce n'est guère plus cher.


Par ailleurs et peut-être surtout, il est essentiel de mettre dans le
message traité par HMAC, outre le mot de passe, du "sel", c'est à dire
une valeur différente pour chaque mot de passe (un compteur, ou un aléa,
à défaut ou en complément l'identifiant du mot de passe); cela évite en
particulier que le coût d'une attaque par dictionnaire de mots de passe
effectuée par un adversaire disposant de la clé (ou ayant moyen de
l'utiliser) soit inversement proportionnelle au nombre d'utilisateurs.
Il est aussi utile de mettre une aussi grande chaine publique que
possible après le mot de passe et le sel, cela augmente le coût de cette
attaque, avec une composante proportionnelle à la taille de la chaine.


François Grieu
Francois Grieu
Le #22798781
Réplexion faite, j'aurais du considérer 2^23 SHA-512 par seconde et par
coeur plutôt que 2^24. Dans l'autre sens, je n'ai pas considéré la
possibilité que l'adversaire utilise des ASIC ou autre solution plus
rapide qu'un CPU.

François Grieu
Thomas Pornin
Le #22803791
According to Francois Grieu
Par définition de HMAC, la taille de clé est contrainte à être au plus
la taille de bloc du hash, donc 1024 bits = 128 octets pour HMAC-SHA512.



Pour être précis, la RFC 2104 précise que HMAC peut utiliser une clé
plus grand que la taille de bloc de la fonction de hachage, mais dans ce
cas on commence par hacher la clé, et c'est ce haché (de longueur 64
octets dans le cas de SHA-512) qui est alors utilisé comme clé. Donc
disons qu'on ne peut pas avoir de clé d'entropie supérieure à 1024 bits
(ce qui est déjà un overkill monumental).


--Thomas Pornin
Francois Grieu
Le #22804541
Le 17/11/2010 15:20, Thomas Pornin a écrit :
According to Francois Grieu
Par définition de HMAC, la taille de clé est contrainte à être au plus
la taille de bloc du hash, donc 1024 bits = 128 octets pour HMAC-SHA512.



Pour être précis, la RFC 2104 précise que HMAC peut utiliser une clé
plus grand que la taille de bloc de la fonction de hachage, mais dans ce
cas on commence par hacher la clé, et c'est ce haché (de longueur 64
octets dans le cas de SHA-512) qui est alors utilisé comme clé. Donc
disons qu'on ne peut pas avoir de clé d'entropie supérieure à 1024 bits
(ce qui est déjà un overkill monumental).



Merci de cette remarque. J'avais été trompé par cette prose
"The authentication key K can be of any length up to B,
the block length of the hash function."
et sa suite dans
http://tools.ietf.org/html/rfc2104#section-2
qui m'a laissé croire (à tort) que le contournement de
cette limite est hors de la stricte définition de HMAC.
Alors qu'en fait c'est spécifié:
http://tools.ietf.org/html/rfc2104#section-3
http://csrc.nist.gov/publications/f...s-198a.pdf


Incidemment, je remarque qu'à cause de cette construction de
HMAC, il est facile de construire des paires de clé équivalentes
(une chaine plus grande que la taille de bloc, et son hash);
et que l'existence d'attaques sur collision du hash rend facile
de construire des triplets de clés équivalentes, dont 2 de même
taille.

Illustration: les 3 clés distinctes suivantes, de 16, 128 et
128 octets respectivement, sont équivalentes pour HMAC-MD5:

a4c0d35c95a63a805915367dcfe6b751

d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f89
55ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5b
960b1dd1dc417b9ce4d897f45a6555d535739ac7f0ebfd0c3029f166d109b18f
75277f7930d55ceb22e8adba79cc155ced74cbdd5fc5d36db19b0ad835cca7e3

d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f89
55ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5b
960b1dd1dc417b9ce4d897f45a6555d535739a47f0ebfd0c3029f166d109b18f
75277f7930d55ceb22e8adba794c155ced74cbdd5fc5d36db19b0a5835cca7e3

car la première est le hash MD5 des autres.


François Grieu
Publicité
Poster une réponse
Anonyme