gouttegd a écrit 1805 commentaires

C'était tellement pratique d'utiliser SKS

Oui, et je pense d’ailleurs que c’est un des nœuds du problème. Le réseau SKS était bien pratique, tellement pratique qu’on était bien content de l’utiliser sans trop se poser de questions. En gros on le tenait pour acquis.

Fun fact : à l’origine le serveur SKS n’était rien de plus qu’un exercice académique. Yaron Minsky faisait une thèse sur la meilleure façon de réconcilier des ensembles, il a écrit SKS comme une « preuve de concept » pour l’algorithme de réconciliation qu’il a inventé (les ensembles à réconcilier étant dans ce cas des trousseaux de clefs OpenPGP). Il n’avait jamais été prévu que SKS devienne un composant essentiel de la distribution des clefs OpenPGP…

Le pire, c’est que j’ai l’impression qu’on est en train de refaire la même erreur avec keys.openpgp.org. Le serveur est très populaire et suscite un enthousiasme certain parmi les utilisateurs… qui sont bien content de l’utiliser sans trop se poser de question et sans se soucier de savoir si c’est une solution pérenne ou non.

Je redoute personnellement que la disponibilité de keys.openpgp.org n’ait pour effet de couper court aux efforts visant à améliorer la distribution des clefs. Après tout pourquoi faire des efforts, on n’a qu’à dire à tout le monde d’utiliser keys.openpgp.org et puis voilà ! Une fois encore, on va confier la distribution des clefs à des bénévoles dont on tient le travail pour acquis.

Par exemple, keys.openpgp.org permet à n’importe quel administrateur de domaine de supporter le protocole de distribution WKD simplement en redirigeant toutes les requêtes WKD sur ce domaine vers keys.openpgp.org (après avoir déposé les clefs du domaine sur le serveur, bien entendu). C’est sympathique, mais ça ne va pas motiver les administrateurs à mettre en place WKD eux-mêmes : pourquoi on se casserait la tête à prendre en charge la distribution des clefs des utilisateurs de notre domaine alors qu’en une ligne dans notre configuration DNS, on peut se décharger entièrement du problème vers les administrateurs de keys.openpgp.org ?

WKD était supposé répartir la charge de la distribution des clefs (chaque domaine distribue ses propres clefs, ce qui à mon sens était raisonnable), mais l’offre de keys.openpgp.org risque d’aboutir à transformer WKD en un simple proxy vers un gros serveur centralisé… et les utilisateurs ne seront peut-être même pas conscients qu’ils utilisent un système centralisé.

une interface web

Pour les webmails, selon le webmail en question il est possible d’utiliser Mailvelope, une extension pour navigateur.

(Je l’ai essayé une fois mais ne l’ai jamais intensivement testé, faute d’intérêt — je n’utilise pas de webmail.)

Pour le cas plus général d’un client (web ou non) sans aucune prise en charge possible de OpenPGP, oui, il est toujours possible en dernier recours de procéder aux opérations de chiffrement/déchiffrement/signature à l’extérieur du client. GPA par exemple a un mode « clipboard », où tu peux écrire ton mail, le chiffrer et/ou le signer, puis copier le résultat vers ton client (et inversement, tu peux y copier un message chiffré que tu as reçu et l’y déchiffrer).

C’est quand même une solution du pauvre, et dans la mesure du possible changer de client serait recommandé, surtout si c’est un client lourd (qu’un webmail ne supporte pas OpenPGP, ce n’est pas surprenant, mais un client lourd, franchement pour moi c’est largement une raison suffisante pour le disqualifier d’office).

Un des gros problèmes de cette solution est qu’elle interdit pratiquement toute utilisation de PGP/MIME, sauf pour les fous furieux qui aiment construire et parser des structures MIME « à la main ».

Du coup on ne dispose pas de la partie privée de cette clé.

Si. :) Mais j’ai simplifié l’explication de l’attaque en laissant de côté certains aspects.

Notamment, dans la clef A, l’espace visible entre le marqueur de fin d’image JPEG (le trait rouge sur le schéma à la fin du journal) et la fin du paquet de clef publique qui le contient est utilisé pour générer un module et un exposant public RSA valide, correspondant à un exposant privé calculé par ailleurs.

Similairement, dans la clef B, il y a un peu d’espace entre l’endroit où la collision est établie et la fin du paquet de clef publique — là encore, on joue sur ces octets pour faire en sorte que le paquet contienne au bout du compte une clef publique valide, correspondant à une clef privée calculée par ailleurs.

À l’arrivée, Mallory possède bien deux clefs OpenPGP « complètes » (parties publiques et privées) — dont une semblant appartenir à Alice, appartenance confirmée par la signature de Charlie.

Bah ce n’est « ni bon ni mauvais », c’est juste qu’à mon avis tu te compliques inutilement la vie (tu dois conserver tes anciennes clefs) et tu compliques la vie de tes correspondants (qui doivent importer une nouvelle clef au lieu de simplement rafraîchir celle qu’ils ont déjà).

(Après ça dépend aussi de la fréquence à laquelle tu génère une nouvelle clef ; si tu fais ça une fois par moi, c’est vraiment se compliquer la vie ; une fois toutes les quelques années, c’est déjà plus raisonnable.)

Par contre si tu ne le fais pas déjà, je recommanderai de révoquer explicitement ton ancienne clef lorsque tu en créer une nouvelle. Sans ça tes correspondants après avoir importé ta nouvelle clef se retrouveront avec deux clefs à ton nom, toutes deux aussi valide l’une que l’autre. Non seulement c’est source de confusion, mais en plus tu n’as aucune garantie qu’ils utiliseront bien la nouvelle clef.

Ça suppose de pouvoir disposer des clés privées sur toutes les machines où l'on souhaite utiliser ces mots de passe.

Pour ça, la meilleure solution à mon sens, et de loin, est d’utiliser un jeton cryptographique (une carte OpenPGP, sous quelque forme que ce soit : une vraie carte à puce, une Yubikey, une Nitrokey, un Gnuk, etc.). Ça fait exactement le job, c’est sûr, et je m’avancerais à dire que c’est user-friendly — la seule barrière est financière, à part ça l’effort demandé à l’utilisateur est vraiment minimal.

J’ai longtemps pensé que ces jetons étaient pour les « utilisateurs avancés », mais je n’en suis plus aussi sûr aujourd’hui. Et comme je vois que les géants du Net (Google and co.) n’hésitent pas à promouvoir des jetons physiques FIDO/U2F pour l’authentification à 2 facteurs, je me dis qu’on peut sans doute bien recommander un jeton physique OpenPGP aux utilisateurs de GnuPG, y compris à ceux qui débutent…

Que penser de cette approche?

Ce n’est pas nécessairement une mauvaise approche, mais j’aurais beaucoup plus de scrupules à la recommander à des débutants — surtout avec aussi peu d’explications que sur la page que tu cites.

Par ailleurs, si l'on ne possède qu'un téléphone sans NFC, n'y a-t-il aucun compromis raisonnable pour utiliser OpenPGP avec icelui?

Si le téléphone a un port USB-C, on peut utiliser une Yubikey 5C / 5Ci / 5C Nano.

Sinon, si on parle de compromis il est toujours possible de choisir de faire suffisamment confiance à son téléphone pour y copier ses clefs privées. Pour ma part c’est niet (je crois que j’aurais encore davantage confiance en un PC sous Windows qu’en un smartphone, tout OS confondu…), mais c’est à chacun de voir.

J’oubliais un « léger » détail (qui peut sembler évident mais on ne sait jamais) : après avoir changé la date d’expiration d’une clef, il faut permettre à tes correspondants de prendre connaissance de la nouvelle date d’expiration, en re-publiant la clef via n’importe quel moyen a été utilisé pour la publier en premier lieu (par exemple, en la ré-envoyant vers un serveur de clefs avec --send-keys).

De manière générale, toute modification de la clef (ajout ou révocation d’une identité, ajout ou révocation d’une sous-clef, changement des algorithmes préférés, changement de la date d’expiration) est une modification locale, qui n’a pas d’effets au-delà de ta machine tant que tu ne re-publies pas explicitement ta clef. À aucun moment GnuPG ne prendra l’initiative de transmettre tes modifications au monde extérieur.

(Le changement de la phrase de passe ne nécessite évidemment pas de re-publication, puisque cela ne concerne que la clef privée.)

Avec la possibilité de se loguer avec la carte à puce (se loguer sur son desktop, ou à distance par ssh sur un serveur), par exemple, en plus du chiffrage/signature. En fait, la partie authentification.

J’ai traité (presque tout¹) ça il y a quelques années ici même. Certaines informations de cette dépêche sont maintenant obsolètes mais je maintiens une version à jour sur mon propre site.

(De manière générale, presque tout ce que je publie sur DLFP est aussi disponible sur mon site.)

Du coup ça me laisse deux ans pour répondre… tranquille, j’ai le temps. :)

Il suffit de changer la date d’expiration, ce qui se fait avec la commande expire dans l’éditeur de clefs de GnuPG :

$ gpg --edit-key alice
La clef secrète est disponible.

sec  rsa2048/54B4CC7749CAE7C3
     créé : 2020-05-13  expire : 2022-05-13  utilisation : SC
     confiance : ultime        validité : ultime
ssb  rsa2048/45EDD81BCE62E9BD
     créé : 2020-05-13  expire : 2022-05-13  utilisation : E
[  ultime ] (1). Alice <alice@example.org>

gpg> expire
Modification de la date d'expiration de la clef principale.
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 0
La clef n'expire pas du tout
Est-ce correct ? (o/N) o

sec  rsa2048/54B4CC7749CAE7C3
     créé : 2020-05-13  expire : jamais      utilisation : SC
     confiance : ultime        validité : ultime
ssb  rsa2048/45EDD81BCE62E9BD
     créé : 2020-05-13  expire : 2022-05-21  utilisation : E
[  ultime ] (1). Alice <alice@example.org>

Attention, comme on le voit ici seule la date d’expiration de la clef principale a été changée. Pour changer celle de la sous-clef de chiffrement, il faut relancer la commande expire après avoir sélectionné ladite sous-clef avec la commande key :

gpg> key 1

sec  rsa2048/54B4CC7749CAE7C3
     créé : 2020-05-13  expire : jamais      utilisation : SC
     confiance : ultime        validité : ultime
ssb* rsa2048/45EDD81BCE62E9BD
     créé : 2020-05-13  expire : 2022-05-21  utilisation : E
[  ultime ] (1). Alice <alice@example.org>

La sous-clef de chiffrement est maintenant sélectionnée (notez l’astérisque ssb*), on peut changer sa date d’expiration :

gpg> expire
Modification de la date d'expiration d'une sous-clef.
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 0
La clef n'expire pas du tout
Est-ce correct ? (o/N) o

sec  rsa2048/54B4CC7749CAE7C3
     créé : 2020-05-13  expire : jamais      utilisation : SC
     confiance : ultime        validité : ultime
ssb* rsa2048/45EDD81BCE62E9BD
     créé : 2020-05-13  expire : jamais      utilisation : E
[  ultime ] (1). Alice <alice@example.org>

gpg> save

À noter que la date d’expiration d’une clef peut être changée à tout moment — y compris une fois que la clef a déjà expiré ! Donc même si tu te réveilles le 21 mai 2022 et que tu te rends comptes que tu as oublié de prolonger la période de validité de ta clef et qu’elle a expiré hier, il n’est pas trop tard pour la changer.

Les changements de date d’expiration sont possibles dans tous les sens : on peut rendre inexpirable une clef qui avait auparavant une date d’expiration tout comme on peut à l’inverse mettre une date d’expiration à une clef qui auparavant n’expirait jamais. Sitôt une nouvelle date d’expiration (y compris « pas de date d’expiration ») mise en place, les dates d’expirations précédentes sont complètement ignorées.

La seule contrainte est qu’il n’est pas possible de spécifier une date d’expiration postérieure au 7 février 2106 — c’est une limitation du format OpenPGP qui stocke les dates sous forme d’entiers non-signés de 32 bits (or 1er janvier 1970 + 2³² secondes ~= 7 février 2106). Mais si tu as besoin d’une clef valable aussi longtemps, autant rendre la clef inexpirable…

Je connais, oui, et j’ai déjà parlé de secret partagé dans un précédent journal.

Quant à un prochain journal avec des notions plus « avancées », ça peut se faire en effet s’il y a de la demande.

?

Les signatures utilisant la cryptographie sur courbes elliptiques (ECC), ça fait déjà plusieurs années que c’est possible. C’est standardisé pour OpenPGP depuis le RFC 6637, et GnuPG supporte ça depuis la version 2.1 — et à ma connaissance la plupart des autres implémentations le supportent aussi.

Mais des signatures ECC ne changeraient rien ici. Le choix de l’algorithme de signature (RSA, DSA, ECDSA ou EdDSA) est orthogonal au choix de l’algorithme de condensation (SHA-1, RIPEMD-160, SHA2-256, etc.), qui est appliqué sur le document à signer avant la signature proprement dite (c’est le résultat de cette opération de condensation qui est donné en entrée à l’algorithme de signature).

Il est parfaitement possible (bien qu’aucune implémentation ne le fasse par défaut, ça doit être explicitement configuré par l’utilisateur) de condenser avec SHA-1 et de signer ensuite avec une clef ECDSA ou EdDSA. L’attaque rapportée ici fonctionnerait tout aussi bien que dans le cas où c’est RSA qui est utilisé pour signer.

(Tout au plus, une signature faite avec SHA-1 + ECDSA éveillerait davantage de soupçons qu’une signature SHA-1 + RSA, parce que toutes les implémentations supportant ECDSA supportent aussi SHA-2 et l’utilisation de SHA-1 serait donc « surprenante » dans ce contexte — alors qu’on peut penser qu’une signature RSA a été émise par une implémentation plus ancienne ne supportant pas SHA-2.)

Je pense tout de même que le problème est que dans des cas de sécurité sur de longue période comme cela, il faudrait prévoir le maintiens de la sécurité. Comme on doit maintenir des sauvegarde (s'assurer que les disque de sauvegarde ne sont pas mort, qu'ils restent lisibles,…), il faut maintenir encore plus activement la sécurité. Ici l'absence de procédure mise en place correctement nuit gravement à la sécurité de ses données.

Sauf que si tu essaies d’expliquer ça à un utilisateur qui demande seulement à pouvoir continuer à valider ses signatures MD-5, tu vas te prendre un retour de bâton du genre « ah, voilà bien la réponse typique d’un développeur de logiciels libres enfermé dans sa tour d’ivoire et sourd aux attentes des utilisateurs : “explique-moi quel est ton besoin, je t’expliquerai comment t’en passer” ».

C’est d’autant plus contre-productif que dans l’exemple en question, les utilisateurs en question savent bien que leur solution n’est pas sans problèmes. Ils n’ont juste pas le choix : ils ne contrôlent pas tout (comme dans beaucoup de situation, les décisions techniques ne sont pas forcément prises par ceux qui maîtrisent la technique…) et ils doivent juste faire du mieux qu’ils peuvent — alors ce n’est pas en venant leur faire des leçons que tu vas les aider.

Je pense que c'est compliqué.

Je n’ai pas dit le contraire.

Je connais mal OpenPGP, mais il doit être possible d'avoir un certain niveau par défaut et de réactiver des algo sur demande (c'est peut être ce qui est fait) ou de modulariser et d'avoir des paquets -ugly comme le fait gstreamer ou encore de n'accepter que de lire ces algo.

C’est un peu tout ça à la fois qui est fait.

Au niveau du standard (en cours de refonte actuellement, même si c’est beaucoup plus long que tout le monde le souhaiterait), il est par exemple INTERDIT (MUST NOT) de générer de nouveaux messages avec MD-5, mais il est POSSIBLE (MAY) de continuer à supporter MD-5 en lecture uniquement. C’est ce qui arrivera à SHA-1 dans la prochaine version du standard.

Au niveau des implémentations, dans le cas de GnuPG :

• Les trucs vraiment trop vieux sont relégués à GnuPG 1.x, dont c’est la seule raison d’être aujourd’hui ;

• Dans la branche principale, les trucs qui marchent encore mais qu’on n’aime plus trop sont toujours supportés en lecture, mais utilisés en écriture seulement à la demande explicite de l’utilisateur.

Par exemple, seul GnuPG 1.x aujourd’hui peut utiliser des signatures MD-5, GnuPG 2.2 les refuse complètement, même en lecture. Dans le cas de SHA-1, jusqu’à ces derniers mois il n’était plus utilisé par défaut (depuis 2009) mais était toujours utilisable sur demande, et accepté en lecture sauf demande contraire (option --weak-digest-algo SHA1) ; depuis la publication de cette attaque, il n’est plus accepté même en lecture.

Si tes mails sont si vitaux une fois reçu tu peux les déchiffrer et les rechiffrer avec l'algo de ton choix

Sauf qu’apparemment personne ne le fait… C’est d’ailleurs la principale raison pour laquelle la branche 1.4 de GnuPG est maintenue ad vitam aeternam : il y a beaucoup de gens qui veulent pouvoir continuer à déchiffrer des messages datant de l’époque de PGP 2.6.

Oui, ces gens feraient probablement mieux de déchiffrer ces messages une bonne fois pour toute, puis de les re-chiffrer avec une version moderne de GnuPG — pourquoi ne le font-ils pas ? Aucune idée. Peut-être qu’ils ont une excellente raison, peut-être qu’ils ont une raison débile. En attendant, c’est comme ça et il faut bien en tenir compte.

Tu peux ressigner

Même problème que pour le re-chiffrement. Tu peux, oui, mais en pratique ce n’est pas fait, pour une raison ou une autre.

(Un exemple de ces raisons : des experts judiciaires américains ont utilisé OpenPGP pour signer des images de disque dur, qui sont conservées dans les archives du système judiciaire US. Les plus anciennes de ces signatures n’utilisent même pas SHA-1, mais MD-5. Aucun expert n’est chaud pour demander que ces signatures soient refaites avec des algorithmes plus modernes, parce que cela pourrait entraîner la remise en question de toutes les affaires judiciaires où des signatures MD-5 ont été utilisées quelque part dans la chaîne de préservation des preuves…)

Bref, tout ça pour dire que la balance entre sécurité, utilisabilité et interopérabilité est délicate. Les développeurs OpenPGP ont généralement tendance, lorsqu’il faut arbitrer entre ces notions, à favoriser l’interopérabilité tant que la sécurité n’est pas irrémédiablement compromise, et à mon sens ils ont raison. L’alternative, c’est un système non-interopérable dans le genre de Signal, où les développeurs peuvent certes ne faire aucune concession sur la sécurité mais au prix d’un fonctionnement en vase clos qui lie les utilisateurs à un seul fournisseur.

les messages non-protégés par un code de modification d’intégrité

Oups, je voulais bien sûr parler d’un code de vérification d’intégrité, ou de détection de modification (Modification Detection Code ou MDC, dans le jargon du RFC4880).

Pourquoi quoi ?

Pourquoi OpenPGP supporte encore SHA-1 ? Pour la même raison qu’il supporte encore 3DES, IDEA ou RIPEMD160 : parce qu’il faut gérer l’existant — notamment, tous les utilisateurs qui ont des archives d’e-mails qui remontent jusqu’aux années 2000 ou même plus loin. Et ces utilisateurs sont assez nombreux, si on en juge par les cris d’orfraie que reçoivent les développeurs de GnuPG chaque fois qu’ils évoquent la possibilité d’envisager de penser à retirer éventuellement le support d’un vieil algorithme.

Un navigateur web de 2020 peut décider de refuser de communiquer avec un serveur web utilisant des technos d’avant 2017. Une implémentation d’OpenPGP de 2020 doit être capable de lire des e-mails vieux de dix ans ou plus, sauf à mécontenter beaucoup de monde.

Pour info, ce n’est pas la première fois que seule la démonstration d’une attaque permet aux développeurs de convaincre les utilisateurs récalcitrants qu’il faut abandonner tel ou tel algorithme, que c’est un impératif de sécurité et non un caprice de développeurs. En 2018, c’est suite à la publication de l’attaque E-fail que les développeurs de GnuPG ont décidé que ce dernier refuserait désormais de déchiffrer les messages non-protégés par un code de modification d’intégrité — quelque chose qu’ils avaient déjà voulu faire plus tôt… avant de faire marche arrière suite aux plaintes d’utilisateurs qui ne pouvaient plus déchiffrer leurs archives.

Pour cette raison et quelques autres, il y a beaucoup d’inertie dans le monde OpenPGP.

Mais je ne vois pas d'information quant aux dates de publication, édition, etc., ce qui me semble un peu dommage.

L’invitation à « vérifier que vous avec une clef OpenPGPv4 » ou à vérifier que les auto-signatures n’utilisent pas MD5 suggère fortement que ce document a une origine très ancienne…

Et la recommandation « vous devriez utiliser un agent » (en commentaire pour expliquer la présence de l’option use-agent dans le fichier de configuration qu’ils proposent) indique que le document est écrit pour GnuPG 1.x (un tel conseil n’a aucun sens pour GnuPG 2.x, qui utilise un agent que vous le vouliez ou non), ce qui est un énorme red flag.

Fun fact : aujourd’hui (et depuis pas mal de temps déjà) aucune des options figurant dans ce fichier de configuration n’est utile. Tous les comportements voulus sont déjà actifs par défaut.

La seule option significative est cert-digest-algo SHA-512 : elle remplace l’algorithme de condensation utilisé pour les certifications, qui est SHA-256 par défaut, par SHA-512. Et ce changement n’est pas nécessairement une bonne idée. SHA-512 est moins répandu dans les implémentations que SHA-256, donc certifier avec SHA-512 fait courir le risque de se retrouver avec des certifications qui ne seront pas utilisables par tout le monde.

il s'agit de "gpg" sans le "2" mais je ne pense pas que cela ai un impact.

Non en effet. J’ignorais que GnuPG 2 était installé sous le nom gpg sur les systèmes Windows, c’est tout.

Ma question peut sembler naïve mais cette commande n'est-elle pas juste de l'affichage ?

C’est en effet essentiellement une fonction d’affichage, mais elle a des effets de bord, dont celui d’informer l’agent GnuPG de la présence des clefs sur la carte (ou la Yubikey).

Mais dans votre cas, la commande n’a pas d’effets parce que vous avez importé non seulement vos clefs publiques mais aussi vos sous-clefs privées. Du coup, l’agent GnuPG a déjà connaissance des sous-clefs privées, et il ne tient pas compte de ce qu’il trouve sur la Yubikey.

Ici, il aurait suffit d’importer les clefs publiques uniquement, puis d’insérer la Yubikey et de lancer la commande gpg --card-status. Là ça aurait fonctionné du premier coup.

Il faut donc revenir en arrière et supprimer les sous-clefs privées que vous avez importés:

gpg --delete-secret-keys 'B73A9C79!'
gpg --delete-secret-keys '9CC8B2FB!'
gpg --delete-secret-keys '8047B454!'

(Attention à ne pas oublier le ! après l’identifiant de clef.)

Après ça, un gpg --list-secret-keys devrait indiquer ssb# devant chaque sous-clef, confirmant l’absence des sous-clefs privés. On peut donc maintenant ré-insérer la Yubikey et relancer la commande gpg --card-status, qui cette fois-ci devrait avoir l’effet de bord escompté.

L'autre tuto sur lequel je me suis basé est celui-là mais je pense que c'est du même acabit non ?

Il est pire… Recommander une clef maître de 8192 bits, bon sang… Je ne suis même pas allé plus loin que ça, l’auteur ne sait clairement pas de quoi il parle.

C’est du même acabit. J’avais d’ailleurs essayé de le faire comprendre à son auteur à l’époque…

La seconde question à se poser est « Pourquoi un tel guide est nécessaire ? ». La raison est simple : tout pratique et simple à installer que soit GPG, ses paramètres par défaut sont loin d'être optimaux

C’est tout simplement faux. Ce ne serait pas très grave si les conseils donnés pour prétendument « optimiser » les paramètres de GnuPG étaient inoffensifs, mais ce n’est pas le cas : certains affaiblissent la sécurité.

Juste un exemple :

# Limite les algorithmes utilisés
personal-cipher-preferences AES256
personal-digest-preferences SHA512

Je mets ma main à couper que tous ceux qui recopient bêtement ces lignes dans leur gpg.conf, pensant améliorer la sécurité de leur communication en forçant l’utilisation de AES256 et SHA512, n’ont pas la moindre idée de ce qu’ils font réellement.

Alors, pour information : ces deux lignes augmentent considérablement le risque de voir vos messages chiffrés avec 3DES et vos signatures condensées avec SHA1 (les deux algorithmes les plus « faibles » actuellement disponibles dans OpenPGP).

3DES et SHA1 sont encore aujourd’hui obligatoires dans OpenPGP — la prochaine version du standard changera ça, mais on n’en est pas encore là malheureusement et pour l’instant les implémentations se doivent de toujours les supporter. Même si vous ne mentionnez que AES256 dans la liste personal-cipher-preferences, GnuPG rajoutera tacitement 3DES en fin de liste (similairement, SHA1 sera silencieusement ajouté à la liste des personal-digest-preferences). Pourquoi ? PParce que la communication, ça se fait à deux (au moins) et vous n’avez personnellement aucun contrôle sur les algorithmes qui sont supportés par l’implémentation de votre correspondant. 3DES et SHA1 sont les deux seuls algorithmes dont le support est garanti par le standard (encore une fois ça changera avec la prochaine version du standard, mais pour l’instant on est encore au RFC4880), donc avoir ces algorithmes dans la liste assure que quelques soient les autres algorithmes dans la liste, la liste contiendra toujours au moins un algorithme supporté par le logiciel d’en face.

Maintenant, imaginons que le logiciel de votre correspondant supporte AES128 mais pas AES256 (ou que le logiciels supporte ces algos mais que votre correspondant, qui a des opinions fortes en matière d’algorithmes de cryptographie, a choisi de les désactiver). Que va-t-il se passer ? GnuPG doit choisir un algorithme présent à la fois dans la liste personal-cipher-preferences et dans la liste de ceux supportés par le correspondant (liste qu’il trouve dans sa clef publique). Il n’a pas le choix, le seul algorithme commun aux deux listes est 3DES.

Autrement dit, en voulant bêtement forcer GnuPG à utiliser l’algorithme que vous pensez être le plus « fort », vous réduisez considérablement sa marge de manœuuvre et le contraignez en fin de compte à se rabattre sur l’algorithme le plus « faible ».

Alors bon, peut-être que c’est ce que vous voulez, hein. Mais qu’il me soit permis de questionner le bien-fondé de cette « optimisation », et les compétences de ceux qui les recommandent.

cipher-algo AES256
digest-algo SHA512

Ah ben là, je n’ai plus aucun doute sur les compétences de l’auteur. Ces deux lignes ont pour effet de rendre les deux lignes précédentes complètement inutiles. Désormais, GnuPG va complètement ignorer le mécanisme des préférences et systématiquement utiliser les deux algorithmes mentionnés. Outre le problème évident d’interopérabilité que ça pose (et qui mériterait au minimum d’être expliqué dans l’article, histoire que les gens recopiant ça comprennent les implications), ça démontre que l’auteur ne comprend pas comment GnuPG sélectionne les algorithmes à utiliser. À quoi bon perdre du temps à restreindre la liste des algorithmes préférés si c’est pour dire à GnuPG juste après « oh et puis non en fait on s’en fout des préférences, utilise ça et point barre » ?

J’adore aussi le fait que le tuto recommande de mettre la clef principale secrète hors-ligne (et donne les instructions en ce sens), sans jamais discuter du bien-fondé de la manœuvre (c’est pas forcément une mauvaise idée et d’ailleurs je le fais moi-même, mais il y a des avantages et inconvénients qui mériteraient d’être expliqués avant de donner ça comme une bonne pratique à suivre) et surtout sans jamais donner les instructions nécessaires pour utiliser la clef principale mise hors-ligne (alors que c’est quand même une difficulté majeure). le jour où la personne qui a naïvement suivi ce tuto voudra certifier une clef ou modifier son propre trousseau (ce qui nécessite la clef principale), ça va lui faire tout drôle…

Pour info, mon propre tuto pour utiliser GnuPG, en deux étapes :

① Utiliser la dernière version de GnuPG (2.2.x ; pas de GnuPG 1.4, 2.0, ou 2.1) ;

② Utiliser les réglages par défaut ; n’ajoutez une ligne dans votre gpg.conf que si vous êtes capables d’expliquer en long en large et en travers ce que fait cette ligne et pourquoi vous pensez en avoir besoin.

La plupart des « conseils » donnés étaient déjà obsolètes/inutiles/dangereux en 2017…

Du coup, je ne sais pas quelles commandes saisir pour indiquer à GPG que mes clés privés se trouvent sur ma Yubikey sans réimporter localement et ré-exporter. Savez-vous comment faire ?

Il suffit d’utiliser la commande gpg2 --card-status alors que la Yubikey est insérée. L’agent GnuPG va automatiquement créer les “stub keys” pointant vers les clefs privées sur la Yubikey.

Aparté :

en suivant, entre autre, ce tuto.

Sigh… Encore un « tuto » prétendant créer la « clef parfaite », rempli de conseils inutiles, obsolètes, voire même dangereux…

Attention, ma dépêche de 2014 est… une dépêche de 2014. Elle n’a pas été mise à jour depuis sur ce site et certains passages ne sont plus corrects.

Back to basics:

① Quelle est la version de GnuPG utilisée ? Si ce n’est pas une version 2.2.x, mettre à jour vers une 2.2.x avant toute autre chose. Toutes les version 2.0.x et 2.1.x sont obsolètes et la branche 1.4.x n’est là que par souci de compatibilité avec les versions de PGP datant des années 1990.

② Comment as-tu installé GnuPG ? L’as-tu compilé toi-même ? (C’est ce que semble indiquer la ligne pinentry-program /usr/local/bin/pinentry-curses dans ton fichier gpg-agent.conf)

③ Quel est ce fichier ~/.ssh/XXXXX.asc dont tu parles ? Comment l’as-tu généréé ?

Avec les versions récentes de GnuPG, en gros les étapes pour l’authentification SSH sont les suivantes :

① Créer une sous-clef d’authentication et la charger dans le slot correspondant de la carte OpenPGP (de la Yubikey, dans le cas présent).

② Activer le support de SSH dans l’agent GnuPG (enable-ssh-support dans ~/.gnupg/gpg-agent.conf).

③ S’assurer que l’agent GnuPG est lancé au démarrage de la session graphique (parce que ssh ne peut pas le lancer tout seul, contrairement à gpg) et que ssh sait où le contacter, en ajoutant les deux lignes suivantes dans ~/.xprofile (ou tout autre script exécuté au démarrage d’une session):

gpg-connect-agent /bye
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

Après ça, la clef d’authentification devrait automatiquement être disponible pour SSH dès lors que la Yubikey est insérée.

Aucune des manipulations ci-dessus ne devrait affecter le fonctionnement normal de GnuPG ou interférer avec Enigmail. Si elles le font, c’est qu’il y a un problème dans ton installation, qu’il convient de débugger. (Ici, vu le message “GnuPG cannot query your passphrase via pinentry”, je subodore que le problème est davantage lié à l’option pinentry-program /usr/local/bin/pinentry-curses dans ton gpg-agent.conf qu’à une modification de ton .bashrc.)

Tu commence par venir avec tes gros sabots expliquer ta règle intouchable

OK, donc énoncer une opinion en prenant bien soin de la présenter comme une opinion personnelle (« j’ai pour ma part retenu une règle absolue », c’est « arriver avec des gros sabots avec une règle intouchable ». Je prends note.

Par contre celui qui s’offusque de cette opinion et qui en réponse affirme péremptoirement qu’une tabulation ça sert à indenter et pas à autre chose, parce que la sémantique c’est important !, lui ne fait sans doute qu’exprimer un point de vue tout relatif sans aucunement émettre de jugement sur ceux qui ne sont pas d’accord (« les cro-magnons qui sont resté à la mise en forme à base d’espace », c’est sans doute une formule de politesse).

Bien, bien.

Faut arrêter de se prendre la tête pour ce genre de considération.

Là-dessus je te donne entièrement raison, et je me serai bien gardé d’avoir l’outrecuidance de donner mon opinion qui ne concerne que moi si j’avais pu prévoir qu’elle susciterait une réaction pareille. Leçon apprise, désormais je m’en tiendrais à tout ce qui touche à GnuPG.

{
    →   int⋅i;
}

Le premier peut être supprimé par le préprocesseur/minifieur, pas le second, et ce sans aucune forme d’analyse syntaxique.

Si je te suis bien, tu décides que le caractère tabulation sert à indenter exclusivement, et donc qu’un outil (autre que le compilateur, qui ne distingue pas ce caractère des autres caractères blancs) peut se permettre de les supprimer sans aucune analyse ?

Je pense que c’est une très mauvaise idée.

Imaginons que j’ai le code suivant :

size_t
some_function(const char *some_arg)
{
    unsigned i;
    size_t len;
    char buffer[4]

et que je souhaite (ou que le style de code du projet impose) aligner les variables sur une même colonne :

size_t
some_function(const char *some_arg)
{
    unsigned i;
    size_t   len;
    char     buffer[4];

Présentement, je fais ça… à coups d’espace, ce qui apparemment est mal, très mal (ce serait même une des causes de tous les maux de l’informatique moderne, tous ces développeurs qui perdent leur temps à faire de l’ASCII art au lieu d’utiliser les bons caractères pour la bonne tâche).

Heureusement, depuis ce journal, j’ai vu la lumière, je suis passé à un éditeur qui supporte les fins de tabulations élastiques, et désormais chaque fois que je veux aligner quelque chose (que ce soit des commentaires à droite du code ou des déclarations de variable), j’utilise une tabulation et une seule.

C’est formidable, tout va pour le mieux dans le meilleur des mondes.

Jusqu’à ce que mon code passe à la moulinette d’un outil écrit par quelqu’un qui a décidé que le sens du caractère tabulation, c’était d’indenter et non pas de séparer les noms de variable de leur type, et qui conséquemment se permet de supprimer toutes les tabulations sans faire aucune analyse syntaxique pour vérifier qu’il a bel et bien le droit de les supprimer. Et le compilateur derrière de se retrouver avec des unsignedi, size_tlen et charbuffer[4] dont il se demande bien que faire…

La sémantique, c’est bien joli, mais si toi ou un de tes outils donne à des caractères une sémantique distincte de celle spécifiée par le langage et attendue par le compilateur, je pense que tu vas au devant d’ennuis.

Libre à toi de le regretter, mais le fait que dans beaucoup de langages une tabulation a la même signification qu’un espace ou même qu’une fin de ligne, c’est un séparateur de tokens et rien d’autre. Partant, je n’ai aucun scrupule à utiliser l’un ou l’autre (et donc, à utiliser par exemple des espaces pour indenter ou aligner), et je n’ai pas le sentiment de causer la perte de l’informatique. Que ça me fasse passer pour un cro-magnon à tes yeux est le dernier de mes soucis.

Sur ce, j’arrête là, il est évident que la discussion ne mènera nulle part et que ce garage à vélo n’est pas prêt d’être peint.

Dans la figure, les petits marqueurs ressemblant à des guillemets fermant indiquent des tabulations. Les marqueurs des lignes 10 à 13 montrent que la longueur des tabulations est adaptative.

Euh, je ne suis pas sûr que ce soit bien la même fonctionnalité que celle décrite dans le journal.

Dans ton exemple, tu as besoin de quatre tabulations après le X(); pour que le commentaire à la fin de la ligne soit aligné avec les commentaires des lignes suivantes.

Avec des « tabulations élastiques » telles que décrites dans le journal, si j’ai bien compris, tu n’insères qu’un seul caractère tabulation chaque fois que tu as besoin d’aligner, et c’est l’éditeur qui ajuste automatiquement la taille de la tabulation en fonction des lignes avoisinantes.

D’ailleurs, il me semble que ce tu montres dans Kate est en fait le comportement standard des tabulations dans la plupart des éditeurs (aussi décrit dans le journal)… la tabulation n’insère pas un systématiquement un blanc de 8 colonnes de large, elle insère un blanc de la largeur adéquate pour aller jusqu’au prochain tab stop.

Ou alors il y a quelque chose que j’ai raté sur cette image ?

Nulle part je ne propose de ne plus indenter… Je voulais seulement faire remarquer que l’indentation n’a pas de signification particulière dans la plupart des langages (Python et Make étant les deux seules exceptions que je connaisse). Partant de là, je ne comprends qu’on puisse faire un caca nerveux sur le fait que c’est horrible de ne pas respecter la soi-disant sémantique d’un caractère que quasiment tous les langages traitent de la même façon qu’un espace.

Pour la lisibilité du code, c’est l’indentation proprement dite qui est importante, pas la manière de marquer l’indentation. Pour ma part j’ai choisi une manière qui fait que l’indentation ne dépendra pas d’un réglage d’affichage de l’éditeur.

La sémantique c’est important !

Sauf qu’à part dans du code Python ou dans un Makefile, dans la quasi-totalité des cas l’indentation n’a pas de sémantique.

C’est en pensant que l’indentation veut dire quelque chose qu’on en arrive à ce que quelqu’un écrive du code comme ça :

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

… et que le bug passe inaperçu (mais à part ça pas de problème, le code est bien indenté avec des tabulations, l’intention du développeur est bien exprimée… ou pas).