Il y a quelques années, on générait couramment des doubles paires de clefs DSA de 1024 bits
D’abord, il faut noter que DSA n’est plus limité à 1024 bits : on peut avoir des clefs DSA de 2048 ou 3072 bits — en revanche, on ne peut pas aller au-delà de 3072, simplement parce que la spécification de DSA ne le prévoit pas.
on recommande généralement d'utiliser des clefs RSA de 2048 bits ou plus
C’est ce que je recommande en effet (plus précisément, je recommande RSA-4096 pour la clef primaire et RSA-2048 pour les sous-clefs), mais je n’irai pas jusqu’à dire que ça fait consensus. DSA a toujours ses défenseurs.
Je suis donc surpris de lire que RSA ne fait pas partie des algorithmes obligatoires, et qu'il n'est pas envisagé de l'y ajouter.
RSA fait pour l’instant partie des algorithmes qui DEVRAIENT être implémentés, et personne ne semble vouloir discuter pour transformer ce SHOULD en MUST.
The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed.
Donc, si une des deux implémentations ne prend en charge que 80% du standard, seuls les 80% concernés peuvent passer au niveau suivant.
Mais, encore une fois, ce pré-requis n’est exigé que pour faire progresser un RFC sur le « chemin des normes » (Standards Track), ladite progression étant presque complément déconnectée du statut réel du standard.
TLS (RFC 5246), par exemple, n’est encore, officiellement, qu’une « proposition de standard »… Quel meilleur exemple que le statut d’un RFC ne veut pas dire grand’chose ? Quelqu’un va-t-il vraiment dire que TLS n’est pas un « vrai » standard ?
Il me semble pour qu'une RFC soit applicable, il faut 2 implémentations indépendantes.
Pas tout-à-fait. Les deux implémentations indépendantes sont nécessaires pour faire avancer un RFC du statut de « proposition de standard » à celui de « standard Internet » (RFC 2026 & 6410).
Mais le statut de « standard » n’a jamais été nécessaire pour qu’un RFC soit « applicable ». Beaucoup de RFC sont largement déployés tout en restant, officiellement, des « propositions ».
je vois que sur la carte OpenPGP, on peut/doit stocker 2 ou 3 clés. Pourquoi donc?
Une clef de signature, une clef de (dé)chiffrement, et une clef d’authentification.
Pourquoi alors avoir une clé de chiffrement et une clé de signature différentes?
Comme j’essaie de l’expliquer dans le journal, seul RSA permet d’utiliser une même paire de clefs à la fois pour signer/vérifier (signer avec la clef privée, vérifier avec la clef publique) et pour chiffrer/déchiffrer (chiffrer avec la clef publique, déchiffrer avec la clef privée). Les autres algorithmes asymétriques n’ont pas cette flexibilité (une paire ElGamal ou ECDH ne permet que de chiffrer/déchiffrer, une paire DSA ou ECDSA ne permet que de signer).
Et même dans le cas de RSA utiliser une seule paire pour toutes les opérations n’est pas forcément considéré comme une bonne idée (cf. message de khivapia ci-dessus).
Si j'ai 3 clés différentes, j'ai donc 3 clés publiques à communiquer.
On touche là du doigt un problème de vocabulaire récurrent et enquiquinant dans le monde OpenPGP, lié au fait que le terme « clef publique » peut désigner deux choses complètement différentes.
Au sens strict, une « clef publique » est juste un ensemble de quelques valeurs numériques (par exemple, une clef publique RSA est un couple {n,e} où n est le module et e l’exposant de chiffrement), sans aucune autre information. C’est le pendant de la clef privée dans une « paire de clefs ».
Mais dans le monde OpenPGP, on emploie très souvent « clef publique » pour désigner ce qu’il conviendrait plutôt d’appeler un « certificat OpenPGP »¹, et qui comprend :
la clef publique (au sens strict) de la paire de clefs primaire ;
une ou plusieurs identités ;
pour chaque identité, des signatures (qu’il conviendrait d’appeler des certifications) établissant un lien entre la clef publique primaire et cette identité :
au moins une auto-signature (émise par la clef primaire privée) ;
un nombre indéfini de signatures émises par d’autres clefs ;
une ou plusieurs sous-clefs publique (encore une fois, au sens strict).
Ce que les utilisateurs d’OpenPGP manipulent, ce sont des certificats, jamais des clefs publiques au sens strict.
Peu importe le nombre de sous-clefs, quand tu communiques ta « clef publique », tu communiques un certificat contenant toutes les informations ci-dessus (y compris toutes les sous-clefs publiques). Tes correspondants n’ont pas à se soucier de ce que contient ton certificat.
¹ Cette notion de « certificat » a été évitée dans les RFC 2440/4880 pour des raisons politiques (pour ne pas marcher sur les plates-bandes de X.509 et PKIX), d’après un des auteurs desdites RFC.
Ne pas transmettre les clefs, oui. L’ordinateur compromis ne peut pas obtenir du token qu’il lui transfère les clefs — celles-ci ne peuvent pas quitter le token.
En revanche, si l’attaquant a le contrôle de l’ordinateur il peut parfaitement utiliser le token sans en récupérer les clefs, et ainsi faire déchiffrer ou signer des messages à sa guise.
Si l’utilisation du token est protégée par un PIN, pas de problème : soit l’attaquant obtient le PIN (il contrôle la machine, ce n’est pas une difficulté pour lui), soit il attend tranquillement que l’utilisateur se serve de son token et le déverouille pour lui.
On peut réduire un tout petit peu le risque en prenant soin de déconnecter le token après chaque utilisation, mais globalement si ta machine est compromise tu ne ne peux plus avoir la moindre assurance sur la confidentialité ou l’intégrité de tes données et de tes communications.
standard qui à mon avis mériterait bien une remise à jour, mais apparemment le groupe de travail OpenPGP à l’IETF ne se réunit plus.
Au cas où quelqu’un suivrait encore les commentaires de ce journal, je signale que le groupe de travail OpenPGP a en fait décidé de se reformer dans l’objectif de publier un nouveau RFC (temporairement surnommé RFC4880bis) pour mettre à jour le standard OpenPGP.
L’addition de nouveaux mécanismes de dérivation de clefs à partir de la phase de passe est notamment au programme (PKBDF2 et scrypt sont envisagés, et peut-être aussi le vainqueur de la compétition PHC qui se tient actuellement).
Quelqu'un sait comment c'est fait en pratique ? Les 100ms sont valables sur la machine sur laquelle la clef est protégée
C’est l’agent GnuPG qui détermine à son démarrage le nombre d’itérations à utiliser (en gros il appelle en boucle la fonction de condensation jusqu’à ce que 100 ms se soient écoulées). Du coup, c’est 100 ms sur la machine où tourne GnuPG.
Par ailleurs pour vraiment gêner la recherche exhaustive il est bon d'utiliser une fonction de hachage pas très performante […] il ne vaut mieux pas trop compter sur une simple augmentation du nombre d'appels à une fonction optimisée
Complètement d’accord, mais en l’espèce GnuPG ne fait que suivre ce qu’impose le standard OpenPGP (RFC 4880, §3.7 String-to-Key Specifiers et §9.4 Hash Algorithms) — standard qui à mon avis mériterait bien une remise à jour, mais apparemment le groupe de travail OpenPGP à l’IETF ne se réunit plus.
ou est-ce que GnuPG refile à Enigmail ma clé privée pour que celui-ci chiffre/signe?
Surtout pas. En fait, même gpg (le binaire principal de GnuPG) ne voit jamais la clef privée. Le seul composant de GnuPG qui manipule les clefs privées est l’agent GnuPG (gpg-agent).
Dans le cas d’Enigmail, il se passe à peu près ça :
① Enigmail invoque gpg en lui donnant le message à déchiffrer ;
② gpg extrait du message la clef de session chiffrée et l’envoie à l’agent GnuPG ;
③ l’agent demande à l’utilisateur sa phrase de passe (via un programme de la famille pinentry) (si elle n’était pas déjà en cache) ;
④ l’agent lit la clef privée chiffrée depuis le disque dur, la déchiffre à l’aide de la phrase de passe, et l’utilise immédiatement pour déchiffrer la clef de session ;
⑤ l’agent renvoie la clef de session déchiffrée à gpg, qui s’en sert pour déchiffrer le corps du message ;
⑥ gpg renvoie le message déchiffré à Enigmail.
Du coup, il «suffit» d'avoir confiance en GnuPG pour conserver ma clé privée à l'abri?
En GnuPG et dans le système sur lequel il tourne. Si ce dernier est compromis, GnuPG seul ne sauvera pas la mise.
À mon avis, tu confonds le fait de signer et le fait d’accorder ta confiance.
Signer indique que tu sais que la clef appartient bien à qui elle prétend appartenir : tu certifies, auprès de tous ceux qui te font confiance, que telle clef et telle identité sont associées. En signant, tu ne dis absolument rien de la confiance à accorder au titulaire de la clef (hors le cas des trust signature, très peu utilisées en pratique).
Si tu n’as pas confiance dans le titulaire de la clef, pour quelque raison que ce soit (tu penses qu’il est laxiste, qu’il utilise sa clef sur une machine vérolée jusqu’à la moelle, que sa phrase de passe est sur un post-it sous l’écran, etc.), ben… tu dis explicitement à GnuPG que tu ne lui fais pas confiance (ownertrust = never). Les certifications émises par cette clef seront alors systématiquement ignorées, et le laxisme du titulaire n’aura pas de conséquence sur ta toile de confiance.
Je voulais bien sûr dire « toutes les deux ou trois versions majeures du noyau Linux » — sur linuxfr.org, ça me semblait évident, voyons. :-°
Blague à part, il faut lire « tous les deux ou trois ans ans » (mais notez la proposition alternative de jben un peu plus bas, qui parle de deux ou trois mois sur les sous-clefs).
Après, je vois un autre point utile à avoir une date d'expiration plutôt courte (pour moi, c'est deux mois uniquement sur les sous-clefs), c'est que tu force tes correspondants à synchroniser ta clef publique
Le problème, c’est que comme tu le dis toi-même tu n’as aucune garantie que le changement de date d’expiration arrive aux utilisateurs de ta clef publique.
Si Alice repousse la date d’expiration de sa clef tous les deux mois mais que Mallory empêche Bob de mettre à jour sa copie de la clef d’Alice, Bob va se retrouver coincé avec une clef expirée que GnuPG lui interdira formellement d’utiliser.
Là, deux possibilités :
a) Soit Bob renonce à envoyer son message à Alice (mieux vaut ne pas communiquer que communiquer sur un canal non-sûr), et dans ce cas Mallory n’a certes pas compromis la confidentialité de leurs communications, mais il les a empêché de communiquer tout court — moi je compte ça comme une attaque.
b) Soit Bob dit « oh, fuck it, j’envoie en clair », et en voulant à tout prix exiger une communication sécurisée, on obtient exactement le contraire.
Non, ça ce sont les CRL utilisées pour transmettre les révocations de certificats X.509.
Quand tu révoques une clef OpenPGP, la révocation est directement incluse dans la clef publique1. En rafraîchissant celle-ci (via un serveur de clefs ou n’importe quel autre moyen), tu obtiens automatiquement l’information que cette clef est révoquée.
Alerte d’abus de langage : ce qu’on appelle ici la clef publique est en réalité un certificat OpenPGP, qui contient non seulement la clef publique proprement dite mais aussi les identités associées à cette clef et les différentes signatures (dont l’auto-signature de révocation, le cas échéant). ↩
Comment Bob fait-il pour être informé des modifications ? C'est automatique, ou manuel ?
Il doit « rafraîchir » sa copie de la clef d’Alice. Si la clef est disponible sur un serveur de clefs, la commande --refresh-keys Alice s’en chargera.
Attention, utilisée sans arguments, la commande --refresh-keys rafraîchit toutes les clefs du trousseau public. C’est pratique, mais ça occasionne une fuite d’informations : ça révèle d’un coup le contenu de ton trousseau public, et donc les noms de toutes les personnes avec qui tu es potentiellement en contact (même celles dont tu n’as pas signé la clef).
Il existe des outils pour rafraîchir le trousseau automatiquement, périodiquement et à raison d’une clef à la fois.
Il n'y a pas de risque d'avoir des clés obsolètes et de les utiliser quand même ?
Si tu perds ta sous-clef de chiffrement, c’est-à-dire que d’une façon ou d’une autre tu ne l’as plus en ta possession1 (par exemple si le support sur lequel se trouvait la seule copie devient hors d’usage, ou si tu égares ce support), alors oui, tu perds avec elle toute possibilité de lire tous les messages ayant été chiffrés avec cette clef.
En revanche, si la clef est expirée ou révoquée (par exemple parce que tu soupçonnes, voire même tu sais qu’elle a été compromise), ce sont tes correspondants qui ne pourront plus se servir de la sous-clef publique correspondante pour chiffrer de nouveaux messages à ton intention. Toi, de ton côté, tu pourras toujours utiliser la sous-clef privée pour déchiffrer les anciens messages.
C’est en partie l’intérêt de révoquer (ou laisser expirer) une sous-clef au lieu de la supprimer : la clef existe toujours et tu peux toujours t’en servir, mais tu signales à tes correspondants que eux ne doivent plus l’utiliser — alors que supprimer la clef empêcherait certes tes correspondants de s’en servir, mais toi tu ne pourrais plus t’en servir non plus.
Ou si tu oublies la phrase de passe, ce qui revient au même : tu ne peux plus utiliser la clef. ↩
Si, mais c’est une addition récente au standard (RFC 6637).
GnuPG permet d’utiliser les courbes elliptiques depuis la version 2.1.0, mais pas par défaut. Il faut utiliser le « mode expert » (option --expert) pour se voir offrir la possibilité de générer des clefs ECC.
Pourquoi ? Est-ce uniquement à cause de l'historique ?
Je crois que l’introduction des courbes elliptiques a été freinée par des histoires de brevets logiciels, mais je ne connais pas les détails.
Si elles ne sont pas utilisées par défaut dans GnuPG aujourd’hui, c’est surtout parce que rare sont les implémentations d’OpenPGP qui les prennent en charge. Générer des clefs ECC par défaut signifierait que les utilisateurs qui acceptent les réglages par défaut se retrouveraient avec des clefs inutilisables pour la plupart des gens (tous ceux qui utilisent des implémentations sans support d’ECC, en particulier tous les utilisateurs de GnuPG 1.4/2.0).
Quels sont les différences d'un point de vue sécurité entre ces deux manière de générer des clés publiques/privées ?
Ce ne sont pas des « manières de générer des clefs », ce sont des types de clefs complètement différents, basés sur des problèmes mathématiques distincts.
Je ne suis absolument pas qualifié pour discuter des différences fondamentales entre la cryptographie « non-ECC » (tous les algorithmes classiques comme RSA, ElGamal, DSA) et la cryptographie ECC (ECDH, ECDSA). Tout ce que je sais, c’est que la plupart des cryptographes admettent que les clefs ECC fournissent une sécurité au moins équivalente à celle de RSA pour des tailles de clefs très inférieures (une clef ECC typique fait 256 bits, et c’est déjà considéré comme fournissant une sécurité supérieure à celle fournie par une clef RSA de 2048 bits).
(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés…)
Si libsodium génére des clefs ECC, la génération peut être plus rapide déjà parce que les clefs sont plus petites. Mais surtout, il est probable que cette bibliothèque utilise une méthode de génération de nombres aléatoires différente.
GnuPG est assez lent à générer des clefs d’une part parce qu’il est assez gourmad en entropie (probablement trop, ce qui a justement fait l’objet d’une discussion récente sur gnupg-devel), et d’autre part parce, du moins sous GNU/Linux, il obtient son entropie depuis le pool bloquant du système (/dev/random). Beaucoup d’autres implémentations puisent à l’inverse dans le pool non-bloquant (/dev/urandom) — pas forcément à tort d’ailleurs.
si rien n'a changé, alors la sortie DOIT etre la meme
Euh, quand je vois le travail que représente le projet Reproducible Builds de Debian, j’ai un doute sur le fait que ce soit si simple.
Notamment :
We have seen variations related to the time of the build, the order of files on the filesystem, the current user, the system hostname, the uname output, (pseudo-)-randomness, and the CPU features or load.
Mais ce qui empêche de faire ça actuellement n’est pas le fait d’avoir « un set de clés limité » (au passage, il n’y a pas de limite au nombre de sous-clefs qu’il est possible d’avoir — si le trousseau typique contient trois clefs, c’est seulement parce qu’on a rarement besoin de plus), c’est le fait qu’on ne signe que la clef primaire et qu’en faisant ça on valide implicitement toutes les sous-clefs, indépendamment de leur usage.
Il existe déjà « un champ qui permet de définir plus finement pour quoi sera utilisée la clef » (RFC 4880 §5.2.3.21, Key Flags), il serait possible de rajouter les usages que tu mentionnes (il faut un consensus de l’IETF pour ça), mais ce qui manque surtout est la possibilité pour Alice de signer uniquement les sous-clefs qu’elle veut parmi toutes les sous-clefs de Bob (par exemple, les sous-clefs de chiffrement, de signature et de réception de dons, mais pas la sous-clef de réception de dividendes), au lieu de signer la clef primaire.
Une carte à puce est un ordinateur très simple dont on peut observer le fonctionnement. Et je ne parle pas des bêtes failles de débordement de buffer qui peuvent permettre de lire complètement la mémoire et donc la clef privée.
Je suis d’accord qu’une carte à puce n’est pas plus infaillible que n’importe quel autre système du même genre. On a déjà réussi à extraire des clefs stockées dans des HSM beaucoup plus chers que des cartes à puces, il est prudent de supposer que les différentes implémentations de la carte OpenPGP ne résisteraient probablement pas davantage face à un attaquant déterminé.
Mais attaquer physiquement une carte à puce suppose de l’avoir à sa disposition. Donc de la soustraire à son propriétaire, qui devrait logiquement s’en apercevoir — et considérer les clefs comme compromises, et donc les révoquer.
La carte à puce n’est pas un outil magique qui va mettre les clefs à l’abri de toutes les menaces (si c’est l’impression qui se dégage de ma dépêche, j’en suis désolé — une section sur les risques spécifiques à la carte à puce, et les risques contre lesquels elle ne protège pas, aurait sans doute été bienvenue). Son rôle premier est de soustraire les clefs aux menaces qui pèsent sur elles tant qu’elles sont sur le disque dur d’un ordinateur vraisembablement connecté à Internet (menaces probablement à la fois plus nombreuses et plus crédibles qu’une attaque matérielle).
Je ne suis pas sûr qu’utiliser des sous-clefs soit pertinent dans le cas que tu présentes, ou alors je ne comprends pas très bien l’objectif.
Est-ce que les interlocuteurs d’Alice (ceux qui vont utiliser la sous-clef destinée à recevoir des dividendes) sont supposés ne pas savoir que la même personne, sous le nom de Bob, reçoit des dons ? Je ne vois pas comment faire ça avec des sous-clefs : quiconque obtient le certificat d’Alice connaîtra toutes les identités et toutes les sous-clefs associées.
J’ai l’impression que ce tu cherches nécessiterait plutôt plusieurs clefs primaires complètement indépendantes.
Si le pire est la perte de la Sous-clef de chiffrement, il faudrait la protéger au moins autant que la clef primaire non ?
Je chipote, mais le pire n’est pas la perte : si tu perds ta sous-clef de chiffrement, tu sais que tu dois la considérer comme compromise, tu la révoques et tu en génères une autre. Dans le pire des cas, seules tes communications passées (jusqu’au moment où tu réalises la perte) sont potentiellement compromises.
Le pire, c’est une exfiltration réalisée de telle sorte que tu ne t’aperçois de rien, parce que tes correspondants vont alors continuer à t’envoyer des messages chiffrés avec cette clef, que ton attaquant pourra lire tranquillement. Tes communications passées et futures sont compromises.
Cela étant, oui, la sous-clef de chiffrement est à protéger avec soin, autant sinon plus que la clef primaire. C’est tout l’intérêt de la mettre sur un token comme la carte OpenPGP.
je pars du principe que chiffrer dans un token est trop lent
Ce n’est pas le cas.
D’une part, le token ne chiffre jamais, il ne fait que déchiffrer — le chiffrement ne requiert que la clef publique de ton correspondant, aucune raison de mettre celle-ci sur un token. Mais je chipote encore (désolé), il est évident que tu parlais de déchiffrer.
D’autre part, on ne déchiffre avec la clef privée rien de plus que la clef de session symétrique avec laquelle on peut ensuite déchiffrer le corps du message. La complexité de l’opération RSA fait que déchiffrer la clef de session est déjà, la plupart du temps, la partie la plus lente (même si le corps du message est beaucoup plus gros que la clef de session, AES est beaucoup plus rapide à déchiffrer, d’autant plus que beaucoup de processeurs ont des instructions AES spécifiques), faire effectuer cette opération par un token ne la ralentit pas beaucoup plus.
Ou alors, il faut révoquer périodiquement cette sous clef.
C’est une possibilité en effet. Je n’irai pas jusqu’à le recommander, mais c’est une option à considérer en fonction des opposants auxquels on pense faire face.
To protect a secret larger than 1024 bits a hybrid technique has to be applied: encrypt the secret with a block cipher and apply secret sharing to just the key.
Hum, dans le cas où le secret est une clef privée OpenPGP, c’est superflu : la clef est déjà chiffrée par GnuPG. Plutôt que de rajouter une couche de chiffrement et de partager la clef qui chiffre la clef, il vaudrait mieux utiliser une phrase de passe longue et complètement aléatoire, que l’on partagera ensuite avec ssss.
Juste un questionnement néanmoins sur le fait de l'imprimer : les imprimantes sont-elles dignes de confiance?
Aucune idée, mais parmi ce qui me vient à l’esprit :
Même sous sa forme exportée par paperkey, la clef reste protégée par la phrase de passe (elle est toujours chiffrée) — donc on n’envoie pas la clef « à poil » vers l’imprimante.
Peu de risque a priori si l’imprimante est directement connectée à l’ordinateur, par USB ou câble parallèle.
Si c’est une imprimante réseau, personnellement je me méfierais davantage de ce qui peut se passer entre ma machine et l’imprimante, que de l’imprimante proprement dit. Je ne connais pas très bien les protocoles d’impression (je ne les connais pas du tout en fait), mais je ne serais pas surpris qu’ils fassent tout circuler en clair.
On peut envisager de configurer le pare-feu local pour bloquer tous les paquets en provenance de l’imprimante et à destination de l’extérieur. En fait ça me semblerait une bonne chose à faire de toute façon, même si on n’envisage pas d’imprimer des clefs OpenPGP.
il n'est pas facile de trouver une info claire et pas trop datée sur les internets.
Tout-à-fait, c’est une des raisons qui m’ont poussé à écrire ce journal (et à écrire la dépêche de décembre dernier).
Aucun des documents actuellement disponibles que j’ai trouvé ne parle de GnuPG 2.1. Bon, ça peut se comprendre, ce dernier est n’est sorti en version stable qu’à l’automne 2014. Mais ce qui est moins compréhensible, c’est que la plupart de ces documents ne parlent en fait même pas de GnuPG 2.0, mais exclusivement de GnuPG 1.4.
C’est très dommage, parce que GnuPG 2.0 rendait déjà plusieurs de ces documents obsolètes même au moment où ils ont été écrits.
ce que leur conseille Mozilla c'est aussi de proposer des technologie plus récentes comme TLS 1.2 avec AES
Il va y avoir du boulot, parce qu’en l’état, on a l’impression que leurs serveurs sont bloqués quinze ans dans le passé : TLS 1.0 maximum (TLS 1.2 date de 2008, et TLS 1.3 approche), re-négociation non-sécurisée, AES en mode CBC uniquement…
je ne vois en revanche pas de problèmes quand à chiffrer d'abord, compresser ensuite.
Le texte chiffré est censé être indistinguable d’un flux d’octets aléatoires, tu ne devrais pas pouvoir le compresser. Si tu y arrives (si la compression réduit effectivement la taille du fichier chiffré), c’est qu’il y a un problème avec l’algorithme de chiffrement.
[^] # Re: RSA
Posté par gouttegd . En réponse au journal Quelques brèves sur OpenPGP. Évalué à 4.
D’abord, il faut noter que DSA n’est plus limité à 1024 bits : on peut avoir des clefs DSA de 2048 ou 3072 bits — en revanche, on ne peut pas aller au-delà de 3072, simplement parce que la spécification de DSA ne le prévoit pas.
C’est ce que je recommande en effet (plus précisément, je recommande RSA-4096 pour la clef primaire et RSA-2048 pour les sous-clefs), mais je n’irai pas jusqu’à dire que ça fait consensus. DSA a toujours ses défenseurs.
RSA fait pour l’instant partie des algorithmes qui DEVRAIENT être implémentés, et personne ne semble vouloir discuter pour transformer ce SHOULD en MUST.
[^] # Re: comme pour les RFC ?
Posté par gouttegd . En réponse au journal [Les Échos] "Guerre de religions" entre OOxml et l'ODF. Évalué à 3. Dernière modification le 02 juin 2015 à 17:09.
RFC 2026, §4.1.2
Donc, si une des deux implémentations ne prend en charge que 80% du standard, seuls les 80% concernés peuvent passer au niveau suivant.
Mais, encore une fois, ce pré-requis n’est exigé que pour faire progresser un RFC sur le « chemin des normes » (Standards Track), ladite progression étant presque complément déconnectée du statut réel du standard.
TLS (RFC 5246), par exemple, n’est encore, officiellement, qu’une « proposition de standard »… Quel meilleur exemple que le statut d’un RFC ne veut pas dire grand’chose ? Quelqu’un va-t-il vraiment dire que TLS n’est pas un « vrai » standard ?
[^] # Re: comme pour les RFC ?
Posté par gouttegd . En réponse au journal [Les Échos] "Guerre de religions" entre OOxml et l'ODF. Évalué à 8.
Pas tout-à-fait. Les deux implémentations indépendantes sont nécessaires pour faire avancer un RFC du statut de « proposition de standard » à celui de « standard Internet » (RFC 2026 & 6410).
Mais le statut de « standard » n’a jamais été nécessaire pour qu’un RFC soit « applicable ». Beaucoup de RFC sont largement déployés tout en restant, officiellement, des « propositions ».
[^] # Re: Pourquoi 3 clés?
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 5.
Une clef de signature, une clef de (dé)chiffrement, et une clef d’authentification.
Comme j’essaie de l’expliquer dans le journal, seul RSA permet d’utiliser une même paire de clefs à la fois pour signer/vérifier (signer avec la clef privée, vérifier avec la clef publique) et pour chiffrer/déchiffrer (chiffrer avec la clef publique, déchiffrer avec la clef privée). Les autres algorithmes asymétriques n’ont pas cette flexibilité (une paire ElGamal ou ECDH ne permet que de chiffrer/déchiffrer, une paire DSA ou ECDSA ne permet que de signer).
Et même dans le cas de RSA utiliser une seule paire pour toutes les opérations n’est pas forcément considéré comme une bonne idée (cf. message de khivapia ci-dessus).
On touche là du doigt un problème de vocabulaire récurrent et enquiquinant dans le monde OpenPGP, lié au fait que le terme « clef publique » peut désigner deux choses complètement différentes.
Au sens strict, une « clef publique » est juste un ensemble de quelques valeurs numériques (par exemple, une clef publique RSA est un couple {n,e} où n est le module et e l’exposant de chiffrement), sans aucune autre information. C’est le pendant de la clef privée dans une « paire de clefs ».
Mais dans le monde OpenPGP, on emploie très souvent « clef publique » pour désigner ce qu’il conviendrait plutôt d’appeler un « certificat OpenPGP »¹, et qui comprend :
Ce que les utilisateurs d’OpenPGP manipulent, ce sont des certificats, jamais des clefs publiques au sens strict.
Peu importe le nombre de sous-clefs, quand tu communiques ta « clef publique », tu communiques un certificat contenant toutes les informations ci-dessus (y compris toutes les sous-clefs publiques). Tes correspondants n’ont pas à se soucier de ce que contient ton certificat.
¹ Cette notion de « certificat » a été évitée dans les RFC 2440/4880 pour des raisons politiques (pour ne pas marcher sur les plates-bandes de X.509 et PKIX), d’après un des auteurs desdites RFC.
[^] # Re: Confier sa clé privée à des logiciels
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Ne pas transmettre les clefs, oui. L’ordinateur compromis ne peut pas obtenir du token qu’il lui transfère les clefs — celles-ci ne peuvent pas quitter le token.
En revanche, si l’attaquant a le contrôle de l’ordinateur il peut parfaitement utiliser le token sans en récupérer les clefs, et ainsi faire déchiffrer ou signer des messages à sa guise.
Si l’utilisation du token est protégée par un PIN, pas de problème : soit l’attaquant obtient le PIN (il contrôle la machine, ce n’est pas une difficulté pour lui), soit il attend tranquillement que l’utilisateur se serve de son token et le déverouille pour lui.
On peut réduire un tout petit peu le risque en prenant soin de déconnecter le token après chaque utilisation, mais globalement si ta machine est compromise tu ne ne peux plus avoir la moindre assurance sur la confidentialité ou l’intégrité de tes données et de tes communications.
[^] # Re: Chiffrement des clefs, dérivation et recherche exhaustive
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Au cas où quelqu’un suivrait encore les commentaires de ce journal, je signale que le groupe de travail OpenPGP a en fait décidé de se reformer dans l’objectif de publier un nouveau RFC (temporairement surnommé RFC4880bis) pour mettre à jour le standard OpenPGP.
L’addition de nouveaux mécanismes de dérivation de clefs à partir de la phase de passe est notamment au programme (PKBDF2 et scrypt sont envisagés, et peut-être aussi le vainqueur de la compétition PHC qui se tient actuellement).
Affaire à suivre…
[^] # Re: Chiffrement des clefs, dérivation et recherche exhaustive
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
C’est l’agent GnuPG qui détermine à son démarrage le nombre d’itérations à utiliser (en gros il appelle en boucle la fonction de condensation jusqu’à ce que 100 ms se soient écoulées). Du coup, c’est 100 ms sur la machine où tourne GnuPG.
Complètement d’accord, mais en l’espèce GnuPG ne fait que suivre ce qu’impose le standard OpenPGP (RFC 4880, §3.7 String-to-Key Specifiers et §9.4 Hash Algorithms) — standard qui à mon avis mériterait bien une remise à jour, mais apparemment le groupe de travail OpenPGP à l’IETF ne se réunit plus.
[^] # Re: Confier sa clé privée à des logiciels
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Surtout pas. En fait, même gpg (le binaire principal de GnuPG) ne voit jamais la clef privée. Le seul composant de GnuPG qui manipule les clefs privées est l’agent GnuPG (gpg-agent).
Dans le cas d’Enigmail, il se passe à peu près ça :
① Enigmail invoque gpg en lui donnant le message à déchiffrer ;
② gpg extrait du message la clef de session chiffrée et l’envoie à l’agent GnuPG ;
③ l’agent demande à l’utilisateur sa phrase de passe (via un programme de la famille pinentry) (si elle n’était pas déjà en cache) ;
④ l’agent lit la clef privée chiffrée depuis le disque dur, la déchiffre à l’aide de la phrase de passe, et l’utilise immédiatement pour déchiffrer la clef de session ;
⑤ l’agent renvoie la clef de session déchiffrée à gpg, qui s’en sert pour déchiffrer le corps du message ;
⑥ gpg renvoie le message déchiffré à Enigmail.
En GnuPG et dans le système sur lequel il tourne. Si ce dernier est compromis, GnuPG seul ne sauvera pas la mise.
[^] # Re: Utilité des sous-clés
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Oui. La clef primaire et la ou les identité(s) associée(s), plus exactement.
Il ne peut pas le savoir. Ce n’est pas pour rien qu’on parle de confiance envers le titulaire (ownertrust)…
[^] # Re: Utilité des sous-clés
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
À mon avis, tu confonds le fait de signer et le fait d’accorder ta confiance.
Signer indique que tu sais que la clef appartient bien à qui elle prétend appartenir : tu certifies, auprès de tous ceux qui te font confiance, que telle clef et telle identité sont associées. En signant, tu ne dis absolument rien de la confiance à accorder au titulaire de la clef (hors le cas des trust signature, très peu utilisées en pratique).
Si tu n’as pas confiance dans le titulaire de la clef, pour quelque raison que ce soit (tu penses qu’il est laxiste, qu’il utilise sa clef sur une machine vérolée jusqu’à la moelle, que sa phrase de passe est sur un post-it sous l’écran, etc.), ben… tu dis explicitement à GnuPG que tu ne lui fais pas confiance (ownertrust = never). Les certifications émises par cette clef seront alors systématiquement ignorées, et le laxisme du titulaire n’aura pas de conséquence sur ta toile de confiance.
[^] # Re: Unité de mesure
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Je voulais bien sûr dire « toutes les deux ou trois versions majeures du noyau Linux » — sur linuxfr.org, ça me semblait évident, voyons. :-°
Blague à part, il faut lire « tous les deux ou trois ans ans » (mais notez la proposition alternative de jben un peu plus bas, qui parle de deux ou trois mois sur les sous-clefs).
[^] # Re: À propos de l'expiration des clefs
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Le problème, c’est que comme tu le dis toi-même tu n’as aucune garantie que le changement de date d’expiration arrive aux utilisateurs de ta clef publique.
Si Alice repousse la date d’expiration de sa clef tous les deux mois mais que Mallory empêche Bob de mettre à jour sa copie de la clef d’Alice, Bob va se retrouver coincé avec une clef expirée que GnuPG lui interdira formellement d’utiliser.
Là, deux possibilités :
a) Soit Bob renonce à envoyer son message à Alice (mieux vaut ne pas communiquer que communiquer sur un canal non-sûr), et dans ce cas Mallory n’a certes pas compromis la confidentialité de leurs communications, mais il les a empêché de communiquer tout court — moi je compte ça comme une attaque.
b) Soit Bob dit « oh, fuck it, j’envoie en clair », et en voulant à tout prix exiger une communication sécurisée, on obtient exactement le contraire.
[^] # Re: Perte des communications passées ?
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 5.
Non, ça ce sont les CRL utilisées pour transmettre les révocations de certificats X.509.
Quand tu révoques une clef OpenPGP, la révocation est directement incluse dans la clef publique1. En rafraîchissant celle-ci (via un serveur de clefs ou n’importe quel autre moyen), tu obtiens automatiquement l’information que cette clef est révoquée.
Alerte d’abus de langage : ce qu’on appelle ici la clef publique est en réalité un certificat OpenPGP, qui contient non seulement la clef publique proprement dite mais aussi les identités associées à cette clef et les différentes signatures (dont l’auto-signature de révocation, le cas échéant). ↩
[^] # Re: Perte des communications passées ?
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 6.
Il doit « rafraîchir » sa copie de la clef d’Alice. Si la clef est disponible sur un serveur de clefs, la commande
--refresh-keys Alices’en chargera.Attention, utilisée sans arguments, la commande
--refresh-keysrafraîchit toutes les clefs du trousseau public. C’est pratique, mais ça occasionne une fuite d’informations : ça révèle d’un coup le contenu de ton trousseau public, et donc les noms de toutes les personnes avec qui tu es potentiellement en contact (même celles dont tu n’as pas signé la clef).Il existe des outils pour rafraîchir le trousseau automatiquement, périodiquement et à raison d’une clef à la fois.
Si (cf. message de jben ci-dessous).
[^] # Re: Perte des communications passées ?
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
Si tu perds ta sous-clef de chiffrement, c’est-à-dire que d’une façon ou d’une autre tu ne l’as plus en ta possession1 (par exemple si le support sur lequel se trouvait la seule copie devient hors d’usage, ou si tu égares ce support), alors oui, tu perds avec elle toute possibilité de lire tous les messages ayant été chiffrés avec cette clef.
En revanche, si la clef est expirée ou révoquée (par exemple parce que tu soupçonnes, voire même tu sais qu’elle a été compromise), ce sont tes correspondants qui ne pourront plus se servir de la sous-clef publique correspondante pour chiffrer de nouveaux messages à ton intention. Toi, de ton côté, tu pourras toujours utiliser la sous-clef privée pour déchiffrer les anciens messages.
C’est en partie l’intérêt de révoquer (ou laisser expirer) une sous-clef au lieu de la supprimer : la clef existe toujours et tu peux toujours t’en servir, mais tu signales à tes correspondants que eux ne doivent plus l’utiliser — alors que supprimer la clef empêcherait certes tes correspondants de s’en servir, mais toi tu ne pourrais plus t’en servir non plus.
Ou si tu oublies la phrase de passe, ce qui revient au même : tu ne peux plus utiliser la clef. ↩
[^] # Re: OpenPGP, libsodium...
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Si, mais c’est une addition récente au standard (RFC 6637).
GnuPG permet d’utiliser les courbes elliptiques depuis la version 2.1.0, mais pas par défaut. Il faut utiliser le « mode expert » (option
--expert) pour se voir offrir la possibilité de générer des clefs ECC.Je crois que l’introduction des courbes elliptiques a été freinée par des histoires de brevets logiciels, mais je ne connais pas les détails.
Si elles ne sont pas utilisées par défaut dans GnuPG aujourd’hui, c’est surtout parce que rare sont les implémentations d’OpenPGP qui les prennent en charge. Générer des clefs ECC par défaut signifierait que les utilisateurs qui acceptent les réglages par défaut se retrouveraient avec des clefs inutilisables pour la plupart des gens (tous ceux qui utilisent des implémentations sans support d’ECC, en particulier tous les utilisateurs de GnuPG 1.4/2.0).
Ce ne sont pas des « manières de générer des clefs », ce sont des types de clefs complètement différents, basés sur des problèmes mathématiques distincts.
Je ne suis absolument pas qualifié pour discuter des différences fondamentales entre la cryptographie « non-ECC » (tous les algorithmes classiques comme RSA, ElGamal, DSA) et la cryptographie ECC (ECDH, ECDSA). Tout ce que je sais, c’est que la plupart des cryptographes admettent que les clefs ECC fournissent une sécurité au moins équivalente à celle de RSA pour des tailles de clefs très inférieures (une clef ECC typique fait 256 bits, et c’est déjà considéré comme fournissant une sécurité supérieure à celle fournie par une clef RSA de 2048 bits).
(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés…)
Si libsodium génére des clefs ECC, la génération peut être plus rapide déjà parce que les clefs sont plus petites. Mais surtout, il est probable que cette bibliothèque utilise une méthode de génération de nombres aléatoires différente.
GnuPG est assez lent à générer des clefs d’une part parce qu’il est assez gourmad en entropie (probablement trop, ce qui a justement fait l’objet d’une discussion récente sur gnupg-devel), et d’autre part parce, du moins sous GNU/Linux, il obtient son entropie depuis le pool bloquant du système (
/dev/random). Beaucoup d’autres implémentations puisent à l’inverse dans le pool non-bloquant (/dev/urandom) — pas forcément à tort d’ailleurs.[^] # Re: oui
Posté par gouttegd . En réponse au message Compilation distribuée DISTCC/CMAKE. Évalué à 7.
Euh, quand je vois le travail que représente le projet Reproducible Builds de Debian, j’ai un doute sur le fait que ce soit si simple.
Notamment :
[^] # Re: Utilité des sous-clés
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 3.
OK, je vois.
Mais ce qui empêche de faire ça actuellement n’est pas le fait d’avoir « un set de clés limité » (au passage, il n’y a pas de limite au nombre de sous-clefs qu’il est possible d’avoir — si le trousseau typique contient trois clefs, c’est seulement parce qu’on a rarement besoin de plus), c’est le fait qu’on ne signe que la clef primaire et qu’en faisant ça on valide implicitement toutes les sous-clefs, indépendamment de leur usage.
Il existe déjà « un champ qui permet de définir plus finement pour quoi sera utilisée la clef » (RFC 4880 §5.2.3.21, Key Flags), il serait possible de rajouter les usages que tu mentionnes (il faut un consensus de l’IETF pour ça), mais ce qui manque surtout est la possibilité pour Alice de signer uniquement les sous-clefs qu’elle veut parmi toutes les sous-clefs de Bob (par exemple, les sous-clefs de chiffrement, de signature et de réception de dons, mais pas la sous-clef de réception de dividendes), au lieu de signer la clef primaire.
[^] # Re: Sous-clef de chiffrement
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 5.
Je suis d’accord qu’une carte à puce n’est pas plus infaillible que n’importe quel autre système du même genre. On a déjà réussi à extraire des clefs stockées dans des HSM beaucoup plus chers que des cartes à puces, il est prudent de supposer que les différentes implémentations de la carte OpenPGP ne résisteraient probablement pas davantage face à un attaquant déterminé.
Mais attaquer physiquement une carte à puce suppose de l’avoir à sa disposition. Donc de la soustraire à son propriétaire, qui devrait logiquement s’en apercevoir — et considérer les clefs comme compromises, et donc les révoquer.
La carte à puce n’est pas un outil magique qui va mettre les clefs à l’abri de toutes les menaces (si c’est l’impression qui se dégage de ma dépêche, j’en suis désolé — une section sur les risques spécifiques à la carte à puce, et les risques contre lesquels elle ne protège pas, aurait sans doute été bienvenue). Son rôle premier est de soustraire les clefs aux menaces qui pèsent sur elles tant qu’elles sont sur le disque dur d’un ordinateur vraisembablement connecté à Internet (menaces probablement à la fois plus nombreuses et plus crédibles qu’une attaque matérielle).
[^] # Re: Utilité des sous-clés
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 2.
Je ne suis pas sûr qu’utiliser des sous-clefs soit pertinent dans le cas que tu présentes, ou alors je ne comprends pas très bien l’objectif.
Est-ce que les interlocuteurs d’Alice (ceux qui vont utiliser la sous-clef destinée à recevoir des dividendes) sont supposés ne pas savoir que la même personne, sous le nom de Bob, reçoit des dons ? Je ne vois pas comment faire ça avec des sous-clefs : quiconque obtient le certificat d’Alice connaîtra toutes les identités et toutes les sous-clefs associées.
J’ai l’impression que ce tu cherches nécessiterait plutôt plusieurs clefs primaires complètement indépendantes.
[^] # Re: Sous-clef de chiffrement
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 4.
Je chipote, mais le pire n’est pas la perte : si tu perds ta sous-clef de chiffrement, tu sais que tu dois la considérer comme compromise, tu la révoques et tu en génères une autre. Dans le pire des cas, seules tes communications passées (jusqu’au moment où tu réalises la perte) sont potentiellement compromises.
Le pire, c’est une exfiltration réalisée de telle sorte que tu ne t’aperçois de rien, parce que tes correspondants vont alors continuer à t’envoyer des messages chiffrés avec cette clef, que ton attaquant pourra lire tranquillement. Tes communications passées et futures sont compromises.
Cela étant, oui, la sous-clef de chiffrement est à protéger avec soin, autant sinon plus que la clef primaire. C’est tout l’intérêt de la mettre sur un token comme la carte OpenPGP.
Ce n’est pas le cas.
D’une part, le token ne chiffre jamais, il ne fait que déchiffrer — le chiffrement ne requiert que la clef publique de ton correspondant, aucune raison de mettre celle-ci sur un token. Mais je chipote encore (désolé), il est évident que tu parlais de déchiffrer.
D’autre part, on ne déchiffre avec la clef privée rien de plus que la clef de session symétrique avec laquelle on peut ensuite déchiffrer le corps du message. La complexité de l’opération RSA fait que déchiffrer la clef de session est déjà, la plupart du temps, la partie la plus lente (même si le corps du message est beaucoup plus gros que la clef de session, AES est beaucoup plus rapide à déchiffrer, d’autant plus que beaucoup de processeurs ont des instructions AES spécifiques), faire effectuer cette opération par un token ne la ralentit pas beaucoup plus.
C’est une possibilité en effet. Je n’irai pas jusqu’à le recommander, mais c’est une option à considérer en fonction des opposants auxquels on pense faire face.
[^] # Re: Merci
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 5.
Hum, dans le cas où le secret est une clef privée OpenPGP, c’est superflu : la clef est déjà chiffrée par GnuPG. Plutôt que de rajouter une couche de chiffrement et de partager la clef qui chiffre la clef, il vaudrait mieux utiliser une phrase de passe longue et complètement aléatoire, que l’on partagera ensuite avec ssss.
Aucune idée, mais parmi ce qui me vient à l’esprit :
Même sous sa forme exportée par paperkey, la clef reste protégée par la phrase de passe (elle est toujours chiffrée) — donc on n’envoie pas la clef « à poil » vers l’imprimante.
Peu de risque a priori si l’imprimante est directement connectée à l’ordinateur, par USB ou câble parallèle.
Si c’est une imprimante réseau, personnellement je me méfierais davantage de ce qui peut se passer entre ma machine et l’imprimante, que de l’imprimante proprement dit. Je ne connais pas très bien les protocoles d’impression (je ne les connais pas du tout en fait), mais je ne serais pas surpris qu’ils fassent tout circuler en clair.
On peut envisager de configurer le pare-feu local pour bloquer tous les paquets en provenance de l’imprimante et à destination de l’extérieur. En fait ça me semblerait une bonne chose à faire de toute façon, même si on n’envisage pas d’imprimer des clefs OpenPGP.
[^] # Re: Merci :-)
Posté par gouttegd . En réponse au journal De la gestion des clefs OpenPGP. Évalué à 5.
Tout-à-fait, c’est une des raisons qui m’ont poussé à écrire ce journal (et à écrire la dépêche de décembre dernier).
Aucun des documents actuellement disponibles que j’ai trouvé ne parle de GnuPG 2.1. Bon, ça peut se comprendre, ce dernier est n’est sorti en version stable qu’à l’automne 2014. Mais ce qui est moins compréhensible, c’est que la plupart de ces documents ne parlent en fait même pas de GnuPG 2.0, mais exclusivement de GnuPG 1.4.
C’est très dommage, parce que GnuPG 2.0 rendait déjà plusieurs de ces documents obsolètes même au moment où ils ont été écrits.
[^] # Re: service-public.fr utilise toujours RC4
Posté par gouttegd . En réponse à la dépêche Firefox : version 38. Évalué à 6.
Il va y avoir du boulot, parce qu’en l’état, on a l’impression que leurs serveurs sont bloqués quinze ans dans le passé : TLS 1.0 maximum (TLS 1.2 date de 2008, et TLS 1.3 approche), re-négociation non-sécurisée, AES en mode CBC uniquement…
[^] # Re: Quel est le problème avec une combinaison de l'existant ?
Posté par gouttegd . En réponse au journal Existe-t-il un bon algorithme qui permet de compresser et de chiffrer en meme temps. Évalué à 7.
Le texte chiffré est censé être indistinguable d’un flux d’octets aléatoires, tu ne devrais pas pouvoir le compresser. Si tu y arrives (si la compression réduit effectivement la taille du fichier chiffré), c’est qu’il y a un problème avec l’algorithme de chiffrement.