Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général la
taille de la clé est fixe pour ce genre d'algo. Comment la clé de cryptage
est-elle générée à partir de la passphrase ? Hashage, autre ?
Ou peut-on lire des choses pertinentes à ce sujet ?
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable pour
protéger une telle clé ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
Je me rends bien compte que cette dernière questio n'a pas grand sens car
tout dépend du niveau de sécurité souhaité.
Mais en gros : à partir de
quelle taille (entropie) une passphrase n'est-elle plus facilement
brute-forçable de nos jours ?
Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général la
taille de la clé est fixe pour ce genre d'algo. Comment la clé de cryptage
est-elle générée à partir de la passphrase ? Hashage, autre ?
Ou peut-on lire des choses pertinentes à ce sujet ?
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable pour
protéger une telle clé ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
Je me rends bien compte que cette dernière questio n'a pas grand sens car
tout dépend du niveau de sécurité souhaité.
Mais en gros : à partir de
quelle taille (entropie) une passphrase n'est-elle plus facilement
brute-forçable de nos jours ?
Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général la
taille de la clé est fixe pour ce genre d'algo. Comment la clé de cryptage
est-elle générée à partir de la passphrase ? Hashage, autre ?
Ou peut-on lire des choses pertinentes à ce sujet ?
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable pour
protéger une telle clé ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
Je me rends bien compte que cette dernière questio n'a pas grand sens car
tout dépend du niveau de sécurité souhaité.
Mais en gros : à partir de
quelle taille (entropie) une passphrase n'est-elle plus facilement
brute-forçable de nos jours ?
mpg wrote on 05/01/2008 17:32:
Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général
la taille de la clé est fixe pour ce genre d'algo. Comment la clé de
cryptage est-elle générée à partir de la passphrase ? Hashage, autre ?
oui, hash avec un algo produisant un digest de la taille de la clé,
c'est le plus simple, ou en retenant les n bits (généralement de poids
forts) nécessaires.
Oki. J'imagine que les clés privées ssh et gpg sont cryptées avec une clé
Ou peut-on lire des choses pertinentes à ce sujet ?
on peut commencer par la crypto PBE (password based encryption) via PKCS
5 (et 7). la protection d'une clé unique ou de session ou encore un
PKCS12 (PFX) par un mot de passe est y bien décrite.
Noté, je vais sans doute regarder ça.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
Cf ci-avant, cela dépends plus des protections que de la taille de la
passphrase - j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment sur un serveur qui autorisait toutes les
tentatives de connexion.
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
mpg wrote on 05/01/2008 17:32:
Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général
la taille de la clé est fixe pour ce genre d'algo. Comment la clé de
cryptage est-elle générée à partir de la passphrase ? Hashage, autre ?
oui, hash avec un algo produisant un digest de la taille de la clé,
c'est le plus simple, ou en retenant les n bits (généralement de poids
forts) nécessaires.
Oki. J'imagine que les clés privées ssh et gpg sont cryptées avec une clé
Ou peut-on lire des choses pertinentes à ce sujet ?
on peut commencer par la crypto PBE (password based encryption) via PKCS
5 (et 7). la protection d'une clé unique ou de session ou encore un
PKCS12 (PFX) par un mot de passe est y bien décrite.
Noté, je vais sans doute regarder ça.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
Cf ci-avant, cela dépends plus des protections que de la taille de la
passphrase - j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment sur un serveur qui autorisait toutes les
tentatives de connexion.
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
mpg wrote on 05/01/2008 17:32:
Je me pose une question sur le stockage sur disque dur (ou autre) de clé
secrètes (gpg, ssh) « protégée » par une pasphrase. Je me demande comment
la passphrase est utilisée pour crytper la clé et avec quel genre
d'algorithme.
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
J'imagine qu'il s'agit de crypto symétrique, genre AES, mais en général
la taille de la clé est fixe pour ce genre d'algo. Comment la clé de
cryptage est-elle générée à partir de la passphrase ? Hashage, autre ?
oui, hash avec un algo produisant un digest de la taille de la clé,
c'est le plus simple, ou en retenant les n bits (généralement de poids
forts) nécessaires.
Oki. J'imagine que les clés privées ssh et gpg sont cryptées avec une clé
Ou peut-on lire des choses pertinentes à ce sujet ?
on peut commencer par la crypto PBE (password based encryption) via PKCS
5 (et 7). la protection d'une clé unique ou de session ou encore un
PKCS12 (PFX) par un mot de passe est y bien décrite.
Noté, je vais sans doute regarder ça.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
Cf ci-avant, cela dépends plus des protections que de la taille de la
passphrase - j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment sur un serveur qui autorisait toutes les
tentatives de connexion.
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
évoquait plus la crypto symétrique.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
documentations... En quoi précisément est-ce que ça en dépend ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
d'attaques.
[...]
- un attaquant qui n'a rien peut essayer de se connecter au serveur. Selon
que celui-ci accepte uniquement les connexions par clé ou pas sur ce
compte, il a le choix ou pas d'essayer d'attaquer en cassant la clé on le
mot de passe. La difficulté de l'attaque sur la clé est en principe
garantie par la taille important de cette dernière et le protocole utilisé.
- un attaquant qui a réussi à accéder à la clé privée cryptée (telle qu'elle
est par exemple stockée sur mon disque dur) peut essayer un autre type
d'attaque : décrypter la clé. C'est potentiellement beaucoup plus facile
que le cas précédent, surtout si la passphrase est trop courte. Il me
semble qu'alors la passphrase devient le maillon le plus faible de la
chaîne.
j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment ...
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
PS : je me connecte fréquemment par clé sur des machines dont je ne contrôle
pas la config du sshd...
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
évoquait plus la crypto symétrique.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
documentations... En quoi précisément est-ce que ça en dépend ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
d'attaques.
[...]
- un attaquant qui n'a rien peut essayer de se connecter au serveur. Selon
que celui-ci accepte uniquement les connexions par clé ou pas sur ce
compte, il a le choix ou pas d'essayer d'attaquer en cassant la clé on le
mot de passe. La difficulté de l'attaque sur la clé est en principe
garantie par la taille important de cette dernière et le protocole utilisé.
- un attaquant qui a réussi à accéder à la clé privée cryptée (telle qu'elle
est par exemple stockée sur mon disque dur) peut essayer un autre type
d'attaque : décrypter la clé. C'est potentiellement beaucoup plus facile
que le cas précédent, surtout si la passphrase est trop courte. Il me
semble qu'alors la passphrase devient le maillon le plus faible de la
chaîne.
j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment ...
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
PS : je me connecte fréquemment par clé sur des machines dont je ne contrôle
pas la config du sshd...
ssh et gpg utilisent des crypto asym., on parlera plus de clés privées.
C'est ce que je voulais dire, en fait. Je ne savais pas que dire clé secrète
évoquait plus la crypto symétrique.
la génération de la clé sym. n'est - par contre - pas directement
définie par ces specs; cela reste assez applicatif - je ne dis pas que
des specs à ce propos n'existent pas mais bien qu'elles émanent d'un
context applicatif particulier.
Je ne suis pas sûr d'avoir bien compris ce dernier paragraphe...
Par ailleurs, à votre avis, quelle taille de passphrase est raisonnable
pour protéger une telle clé ?
elle devrait être choisie en fonction de l'algo de hash utilisé.
En l'occurrence, je ne crois pas en avoir vu la mention dans les
documentations... En quoi précisément est-ce que ça en dépend ?
J'utilise personnellement des mots de passes
relitivement aléatoires de 10 caractères (avec casse, chiffres et
ponctuations) pour protéger tant ma clé privée ssh que ma clé privée gpg,
elle dépend ensuite des possiblités d'attaque sur la clé, par exemple en
ssh si le serveur utilise un temps de réponse croissant à chaque échec
puis bloque l'IP émettrice pdt X mn (10-30) après n (3-5) essais ratés,
8 caractères sont peut être suffisant ... mais 10 est bien, et 12 mieux.
Hum, il semble que quelque chose m'ait échappé sur les possibilités
d'attaques.
[...]
- un attaquant qui n'a rien peut essayer de se connecter au serveur. Selon
que celui-ci accepte uniquement les connexions par clé ou pas sur ce
compte, il a le choix ou pas d'essayer d'attaquer en cassant la clé on le
mot de passe. La difficulté de l'attaque sur la clé est en principe
garantie par la taille important de cette dernière et le protocole utilisé.
- un attaquant qui a réussi à accéder à la clé privée cryptée (telle qu'elle
est par exemple stockée sur mon disque dur) peut essayer un autre type
d'attaque : décrypter la clé. C'est potentiellement beaucoup plus facile
que le cas précédent, surtout si la passphrase est trop courte. Il me
semble qu'alors la passphrase devient le maillon le plus faible de la
chaîne.
j'ai eu une clé/passphrase ssh de 12 car. (UPPER, lower,
digit, _) pétée récemment ...
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
PS : je me connecte fréquemment par clé sur des machines dont je ne contrôle
pas la config du sshd...
un secret est ce "qui [est] connu que d'un certain nombre d'adeptes"
(Littré) - donc les partenaires d'un échange secret, comme le permet une
crypto. symétrique.
ce qui est privé est ce qui reste sous votre contrôle/possession seul.
Vu.
je reformule:
la crypto qui définit comment wrapper par une clé symm. un bi-clé asymm.
(ou une clé privée seule) est bien documentée.
la crypto PBE décrit bien comment une clé privée peut être protégée par
une clé symm. généré à partir d'un passphrase mais elle ne dit pas
toutes les façons qui pourraient être utilisées pour générer cette clé à
partir de ce passphrase (ce choix là - l'algo de hash et son utilisation
par exemple - peuvent ne pas être normaliser pour un produit donné, mais
résulter des choix de ce produit seul).
D'accord. C'est très clair comme ça.
la passphase devrait contenir +/- autant d'entropie que le digest
lui-même, un sha1 160 bits devrait utiliser 28 caractères si ceux-ci
sont dans {A..Z,a..z} - ce point est "mon" raccourci, ce n'est pas un
résultat démontrable et il prend très sûrement une grosse marge.
Je vois. En fait, ce qui est (me semble-t-il) clair sans trop grosse
si le "par clé" correspond (notamment, en gros, ...) à une
authentification kerberos (vérification de signature faite avec la clé
privé de l'utilisateur) le mécanisme est (très généralement) sur ...
mais la question sur un éventuel passphrase ne se pose pas car il
n'intervient pas dans l'authentification (cela peut intervenir en local
pour pouvoir réaliser la signature).
On est d'accord.
l'attaque dont je parlais est une attaque sur un compte - sur le
password assignié à ce compte qui correspond à la passphrase qui sera
hashée et objet de votre question initiale.
ici l'attaque force-brute est possible est le point faible (hormi
passphrase très courte et mot du dictionnaire) serait le manque de
détection d'essai raté par le serveur.
Ah, on ne parlait pas de la même chose. C'est aussi ma faute, j'ai mélangé
oui cela est possible aussi; une clé même chiffrée doit être protégée
autant que faire se peut - sauf si provocateur ou amoureux des défis.
Oki.
dans ce cas, l'attaquant n'aura aucun obstacle externe et seul sa
puissance de calcul conditionnera ses chances de succès; ceci doit
inciter à utiliser des clés longues (AES 256 bits plutôt que DES 56 bits
évidemment); ici la passphrase d'origine peut ne pas intervenir (sauf
attaque dictionnaire ou certitude sur les contraintes, ie nombres de
caractères et jeu utilisé), plus généralement on se ramène à une attaque
sur la clé de wrapping elle même indépendamment de la façon dont elle a
été obtenue.
D'accord. En fait, c'était un peu là une de mes questions initiales : il est
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
un password de compte unix.
Oki.
un secret est ce "qui [est] connu que d'un certain nombre d'adeptes"
(Littré) - donc les partenaires d'un échange secret, comme le permet une
crypto. symétrique.
ce qui est privé est ce qui reste sous votre contrôle/possession seul.
Vu.
je reformule:
la crypto qui définit comment wrapper par une clé symm. un bi-clé asymm.
(ou une clé privée seule) est bien documentée.
la crypto PBE décrit bien comment une clé privée peut être protégée par
une clé symm. généré à partir d'un passphrase mais elle ne dit pas
toutes les façons qui pourraient être utilisées pour générer cette clé à
partir de ce passphrase (ce choix là - l'algo de hash et son utilisation
par exemple - peuvent ne pas être normaliser pour un produit donné, mais
résulter des choix de ce produit seul).
D'accord. C'est très clair comme ça.
la passphase devrait contenir +/- autant d'entropie que le digest
lui-même, un sha1 160 bits devrait utiliser 28 caractères si ceux-ci
sont dans {A..Z,a..z} - ce point est "mon" raccourci, ce n'est pas un
résultat démontrable et il prend très sûrement une grosse marge.
Je vois. En fait, ce qui est (me semble-t-il) clair sans trop grosse
si le "par clé" correspond (notamment, en gros, ...) à une
authentification kerberos (vérification de signature faite avec la clé
privé de l'utilisateur) le mécanisme est (très généralement) sur ...
mais la question sur un éventuel passphrase ne se pose pas car il
n'intervient pas dans l'authentification (cela peut intervenir en local
pour pouvoir réaliser la signature).
On est d'accord.
l'attaque dont je parlais est une attaque sur un compte - sur le
password assignié à ce compte qui correspond à la passphrase qui sera
hashée et objet de votre question initiale.
ici l'attaque force-brute est possible est le point faible (hormi
passphrase très courte et mot du dictionnaire) serait le manque de
détection d'essai raté par le serveur.
Ah, on ne parlait pas de la même chose. C'est aussi ma faute, j'ai mélangé
oui cela est possible aussi; une clé même chiffrée doit être protégée
autant que faire se peut - sauf si provocateur ou amoureux des défis.
Oki.
dans ce cas, l'attaquant n'aura aucun obstacle externe et seul sa
puissance de calcul conditionnera ses chances de succès; ceci doit
inciter à utiliser des clés longues (AES 256 bits plutôt que DES 56 bits
évidemment); ici la passphrase d'origine peut ne pas intervenir (sauf
attaque dictionnaire ou certitude sur les contraintes, ie nombres de
caractères et jeu utilisé), plus généralement on se ramène à une attaque
sur la clé de wrapping elle même indépendamment de la façon dont elle a
été obtenue.
D'accord. En fait, c'était un peu là une de mes questions initiales : il est
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
un password de compte unix.
Oki.
un secret est ce "qui [est] connu que d'un certain nombre d'adeptes"
(Littré) - donc les partenaires d'un échange secret, comme le permet une
crypto. symétrique.
ce qui est privé est ce qui reste sous votre contrôle/possession seul.
Vu.
je reformule:
la crypto qui définit comment wrapper par une clé symm. un bi-clé asymm.
(ou une clé privée seule) est bien documentée.
la crypto PBE décrit bien comment une clé privée peut être protégée par
une clé symm. généré à partir d'un passphrase mais elle ne dit pas
toutes les façons qui pourraient être utilisées pour générer cette clé à
partir de ce passphrase (ce choix là - l'algo de hash et son utilisation
par exemple - peuvent ne pas être normaliser pour un produit donné, mais
résulter des choix de ce produit seul).
D'accord. C'est très clair comme ça.
la passphase devrait contenir +/- autant d'entropie que le digest
lui-même, un sha1 160 bits devrait utiliser 28 caractères si ceux-ci
sont dans {A..Z,a..z} - ce point est "mon" raccourci, ce n'est pas un
résultat démontrable et il prend très sûrement une grosse marge.
Je vois. En fait, ce qui est (me semble-t-il) clair sans trop grosse
si le "par clé" correspond (notamment, en gros, ...) à une
authentification kerberos (vérification de signature faite avec la clé
privé de l'utilisateur) le mécanisme est (très généralement) sur ...
mais la question sur un éventuel passphrase ne se pose pas car il
n'intervient pas dans l'authentification (cela peut intervenir en local
pour pouvoir réaliser la signature).
On est d'accord.
l'attaque dont je parlais est une attaque sur un compte - sur le
password assignié à ce compte qui correspond à la passphrase qui sera
hashée et objet de votre question initiale.
ici l'attaque force-brute est possible est le point faible (hormi
passphrase très courte et mot du dictionnaire) serait le manque de
détection d'essai raté par le serveur.
Ah, on ne parlait pas de la même chose. C'est aussi ma faute, j'ai mélangé
oui cela est possible aussi; une clé même chiffrée doit être protégée
autant que faire se peut - sauf si provocateur ou amoureux des défis.
Oki.
dans ce cas, l'attaquant n'aura aucun obstacle externe et seul sa
puissance de calcul conditionnera ses chances de succès; ceci doit
inciter à utiliser des clés longues (AES 256 bits plutôt que DES 56 bits
évidemment); ici la passphrase d'origine peut ne pas intervenir (sauf
attaque dictionnaire ou certitude sur les contraintes, ie nombres de
caractères et jeu utilisé), plus généralement on se ramène à une attaque
sur la clé de wrapping elle même indépendamment de la façon dont elle a
été obtenue.
D'accord. En fait, c'était un peu là une de mes questions initiales : il est
Je ne suis pas sûr de comprendre ce que tu veux dire par « une
clé/passphrase » pétée.
un password de compte unix.
Oki.
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
mpg wrote on 06/01/2008 15:03:
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
mpg wrote on 06/01/2008 15:03:
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
mpg wrote on 06/01/2008 15:03:
D'accord. En fait, c'était un peu là une de mes questions initiales
[...] Je me demandais en gros ce qu'il faut prévoir
comme passphrase pour que ça ne soit pas un point
démesurément faible de la chaîne [...]
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
le mot important de ma question.
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
caractères soient choisis rigoureusement au hasard et de façon indépendante
(ce qui n'est souvent pas la cas si on veut avoir un chance de bien se
rappeler le mdp). En ce qui me concerne, je suis pas sûr d'être prêt à
mémoriser et à saisir plusieurs fois par jour une telle passphrase.
D'où une reformulation plus claire de ma question : y a-t-il moyen d'estimer
les moyens (temps fois puissance de calcul) nécessaires de nos jours pour
brute-forcer une passphrase d'entropie n donnée, en fonction de n, et
sachant que pour chaque test il y a, mettons[1] mille itérations d'un hash
donné à calculer ? Histoire d'utiliser une taille de passphrase raisonnable
pour se mettre hors de portée du premier crackeur venu, mais pas forcément
des tous les gouvernements mondiaux réunis, si c'est trop contraignant...
[1] J'imagine que répondre à cette question revient à remplacer
ce « mettons » par quelque chose de précis ?
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
le mot important de ma question.
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
caractères soient choisis rigoureusement au hasard et de façon indépendante
(ce qui n'est souvent pas la cas si on veut avoir un chance de bien se
rappeler le mdp). En ce qui me concerne, je suis pas sûr d'être prêt à
mémoriser et à saisir plusieurs fois par jour une telle passphrase.
D'où une reformulation plus claire de ma question : y a-t-il moyen d'estimer
les moyens (temps fois puissance de calcul) nécessaires de nos jours pour
brute-forcer une passphrase d'entropie n donnée, en fonction de n, et
sachant que pour chaque test il y a, mettons[1] mille itérations d'un hash
donné à calculer ? Histoire d'utiliser une taille de passphrase raisonnable
pour se mettre hors de portée du premier crackeur venu, mais pas forcément
des tous les gouvernements mondiaux réunis, si c'est trop contraignant...
[1] J'imagine que répondre à cette question revient à remplacer
ce « mettons » par quelque chose de précis ?
s'assurer que la passphrase contient +/- autant d'entropie que la clé
(radoterais-je ?)
Non, ça va, j'ai compris. En fait, j'y reviendrait, c'était « démesurément »
le mot important de ma question.
pour que la passphrase ne soit pas un point démesurément faible, il faut
que 72^n ne soit pas très petit devant 2^128; ou encore, c'est pareil,
il faut que la difficulté d'attaque du passphrase soit comparable à
celle de la clé (ou son entropie, d'où le point de mon post précédent).
C'est-à-dire que n doit être de l'ordre de 20 ou 21, en supposant que les
caractères soient choisis rigoureusement au hasard et de façon indépendante
(ce qui n'est souvent pas la cas si on veut avoir un chance de bien se
rappeler le mdp). En ce qui me concerne, je suis pas sûr d'être prêt à
mémoriser et à saisir plusieurs fois par jour une telle passphrase.
D'où une reformulation plus claire de ma question : y a-t-il moyen d'estimer
les moyens (temps fois puissance de calcul) nécessaires de nos jours pour
brute-forcer une passphrase d'entropie n donnée, en fonction de n, et
sachant que pour chaque test il y a, mettons[1] mille itérations d'un hash
donné à calculer ? Histoire d'utiliser une taille de passphrase raisonnable
pour se mettre hors de portée du premier crackeur venu, mais pas forcément
des tous les gouvernements mondiaux réunis, si c'est trop contraignant...
[1] J'imagine que répondre à cette question revient à remplacer
ce « mettons » par quelque chose de précis ?