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) ?
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
Francois Grieu
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
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.
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
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
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.
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
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
According to Francois Grieu <fgrieu@gmail.com>:
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).
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 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/fips/fips198/fips-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:
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/fips/fips198/fips-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:
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/fips/fips198/fips-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:
