Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

clé secrète et passphrase

7 réponses
Avatar
mpg
Bonjour,

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,
sachant que celles-ci ne sont en principe laissée que sur des machines en
lesquelles j'ai plutôt confiance (tant niveau sécurité que fiabilité du
root).

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 ?

Merci d'avance pour vos lumière.

Manuel.

7 réponses

Avatar
Sylvain
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.

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.

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.

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.

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é.

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.

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é.


cela dépend aussi de cela.

Mais en gros : à partir de
quelle taille (entropie) une passphrase n'est-elle plus facilement
brute-forçable de nos jours ?


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.

Sylvain.

Avatar
mpg
Le (on) dimanche 06 janvier 2008 00:36, Sylvain a écrit (wrote) :

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

évoquait plus la crypto symétrique.

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é

suffisamment longue, et que donc il s'agit plutôt d'un hash que des bits
necéssaires, la passphrase étant sans doute souvent plus courte que la 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

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.

Je croyais que l'attaque sur la passphrase qui protège la clé se faisait
hors-ligne. En effet si j'utilise ssh-add (hors de toute tentative de
connexion), je reçois un message d'erreur quand j'entre un mpd incorrect :
cela semble indiquer que ça ne dépend en rien des réglages d'un éventuel
serveur.

En fait, je voyais les choses comme suit :

- 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.

Où me trompé-je ?

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

clé/passphrase » pétée.

Manuel.

PS : je me connecte fréquemment par clé sur des machines dont je ne contrôle
pas la config du sshd...


Avatar
Sylvain
mpg wrote on 06/01/2008 01:21:

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.


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.

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...



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).

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 ?


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.

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é.


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).

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.

- 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.


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.

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.

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.


un password de compte unix.

PS : je me connecte fréquemment par clé sur des machines dont je ne contrôle
pas la config du sshd...


si c'est par clé (et non par compte dont le mot de passe est wrappé avec
la clé publique du serveur), je ne vois pas de menaces évidentes coté
serveur; votre attention doit plus porter sur la protection locale de
votre clé privée - par exemple en la stockant dans un token
crytographique d'où elle ne sort jamais, plutôt qu'un fichier chiffré
sur un disque pouvant être lu/copié/volé.

Sylvain.



Avatar
mpg
Le (on) dimanche 06 janvier 2008 02:05, Sylvain a écrit (wrote) :

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

démonstration, c'est que si la passphrase contient notablement moins
d'entropie que le digest (par exemple, c'est un mot de moins de 6 lettres,
du dictionnaire), alors elle constitue le point faible de la chaîne.

Donc, ce que vous dites, c'est qu'heuristiquement, la sécurité est maximale
quand l'entropie de la passphrase de est comparable à celle du digest (en
deçà, c'est créer un point faible, en delà, c'est gâcher). Tout ça à la
louche, bien sûr...

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é

trop de choses et je n'aurais pas dû parler de clé ssh peut-être. Je
pensais à la base à la protection de la clé à proprement parler (surtout
pour une clé PGP) plus qu'à celle du compte. Il est évident que si on parle
de la protection d'un compte, l'attaque par force brute contre un mot de
passe sera la plus dangereuse (à moins que le mot de passe n'ait une
entropie considérable et/ou que le serveur soit configuré de façon à éviter
ça, comme vous dites).

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

clair que dans des conditions extrêmes (passhrase dans le dictionnaire...)
la passphrase consitue le point faible du système. 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 (sachant qu'il faut de toutes façons tout
faire pour que l'attaquant n'ait jamais accès au fichier contenant la clé
privée crytpée, afin d'éviter ce type d'attaque).

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.


Manuel.


Avatar
Sylvain
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 ?)

disons que le bi-clé pgp est chiffré par une clé AES 128 bits.
supposons que cette clé est générée comme un hash MD2, 4 ou 5 d'une
passphrase.
considérons également qu'aucune autre attaque qu'une force-brute soit
possible pour corrompre cette clé.

si l'entropie de la passphrase était infinie, l'attaquant n'a d'autre
solution que d'énumérer les clés possibles, donc max. 2^128 essais.

mais bien sur la passphrase est finie et son entropie aussi, donc il
peut être plus facile d'énumérer tous les passphrases possibles (on
s'ajoute un hash mais on fera sûrement moins d'essai).
si elle contient n caractères pris dans {A..Z,a..z,0..9,[une dizième de
ponctuation]} il y aura 72^n variantes possibles.

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).

Sylvain.


Avatar
mpg
Le (on) dimanche 06 janvier 2008 17:19, Sylvain a écrit (wrote) :

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 »

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 ?

Bon, vous allez me répondre que je n'ai qu'à faire le calcul. Pas faux. Mais
comme je n'ai pas trop l'habitude de ce genre d'estimations, je me disais
que peut-être il existe des tables ou autre...

Manuel.



Avatar
Sylvain
mpg wrote on 06/01/2008 18:06:

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.


;) la remarque valait pour moi ... et pour introduire qu'il est
difficile d'en dire plus, ie de définir une vérité simple à énoncer qui
résumerait parfaitement toute la complexité d'une stratégie de protection.

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.


c'est bien sur quasi impossible et personne ne le fait.
d'où mon autre suggestion: stocker la clé dans un token (et non dans un
fichier) qui utilisera un pin / mdp bcp plus court mais avec bcp moins
d'essai (3 à 5) avant de se bloquer (définitivement ou non selon le
schéma de sécurité).

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 ?


1000 (1024) est en effet un nombre standard d'itération du hash.

l'expérience montre qu'une entropie de 2^56 bits est aujourd'hui
accessible, 2^64 bits paraissent également faible face à un attaquant
sérieux mais cela écartera haut la main le premier crackeur, cela
correspond à un mdp de 10 caractères (avec caractères dans jeu
précedemment listé).
disons que 10 est le minimum, 12 ou 14 donnent un peu plus de sécurité.

donner une estimation du temps de calcul est difficile / impossible si
on ignore tout de la puissance de calcul de l'attaquant; sur un PC moyen
un cycle de 1024 SHA1 demande de l'ordre de 1 à 2 ms.

Sylvain.