PGP - Je ne chiffre plus les emails

Public key cryptography¹ - xkcd

Contexte

[Spoiler]: Avant que le communauté des utilisateurs irréductibles de PGP² ne me saute dessus à bras raccourcis, laissez-moi vous donner quelques éléments de contexte.

J’utilise le chiffrement PGP depuis bientôt 20 ans, une des rares solutions qui permettait de se soustraire à la curiosité envahissante de nos amis Chinois quand j’habitais en Chine³. C’est à la même période d’ailleurs et pour des raisons similaires que j’abandonne Windows et bascule mon environnement de travail sous Linux.

Au sein de la société qui m’emploie dans les années 2010 en Asie du Sud-Est, le recours au chiffrement des pièces jointes est systématique - au format .txt, pas MS Word bien sûr. Expliquer à nos client comment installer et utiliser un logiciel de chiffrement prend parfois du temps mais on y parvient. Tout le monde jongle avec les clés de chacun - celles dédiées aux déplacements, celles qui sont égarées, celles dont les mots de passe sont perdus, celles qui sont créées sans prévenir… Mais ça fonctionne. Non sans quelques frictions et grognements.

L’apparition des messageries instantanées, WhatsApp, Telegram brièvement puis Signal révolutionne les échanges et sonne - enfin - le glas des pièces jointes chiffrées envoyées par email. J’entretiens néanmoins mon petit parc de clés PGP et utilise des clients PGP-compatibles tels que Thunderbird (desktop) et OpenKeyChain avec K9 puis Fairemail (Android).

Bon élève, je suis les bonne pratiques⁴ à la lettre: je bidouille le fichier gpg.conf, sélectionne Curve25519 et Ed25519, je deviens un virtuose de la CLI gpg2 --expert --full-gen-key pour séparer la clé de certification de ses sous-clés de chiffrement et signature, j’exporte la clé vers le mobile en ôtant la clé principale, choisis des durées de validité courtes, je les renouvelle, les publie sur des serveurs de clé, conserve soigneusement les certificats de révocation dans un container Veracrypt, etc… Bref, les utilisateurs avertis de PGP se reconnaîtront, tout ceci est une vraie plaie à gérer.

Puis, au fur et à mesure des années, abstraction faite de quelques irréductibles, le volume des emails utiles chiffrés en PGP diminue pour tout simplement tomber à zéro. Je ne pense pas avoir reçu une seul email spontanément chiffré à dessein par son émetteur depuis 3 ou 4 ans.

Comme personne ne les utilise plus, j’arrête moi aussi de chiffrer et/ou de signer les emails en PGP.

En conséquence, si vous tombez sur les clés ed25519/0xCAAD364477DA43C8 et ed25519/0xF509244B5E236B2C, sachez qu’elles sont désormais révoquées.

PGP - une impasse technologique?

Le chiffrement PGP existe depuis 20 ans et il est toujours aussi complexe et pénible à utiliser. Quand bien même y parviendrait-on, GPG présente des défauts structurels qui n’ont pas été surmontés depuis sa création. Le sujet est assez bien documenté…

Moxie Marlinspike (le fondateur de Signal) note⁵ que la technologie elle-même, accusant son âge (les années 90) sur le plan de la philosophie de conception, est obsolète et que le protocole PGP ne laisse pas non plus de place à des concepts aujourd’hui essentiels tels que la forward secrecy.

Les clés PGP sont nulles voire dangereuses, leur gestion manuelle est une hérésie, le format OpenPGP et les valeurs par défaut craignent, les clients de messagerie sont horribles et la forward secrecy n’existe pas assène non sans malice⁶ Matthew Green, ajoutant qu’un détracteur de PGP n’est qu’un utilisateur de PGP qui a utilisé le logiciel pendant un certain temps.

Il ne s’agit pas de l’outil PGP lui-même, ni des outils en général mais du modèle de clé PGP à long terme qui m’a déçu constate⁷ Filippo Valsorda, très fin connaisseur du protocole. Tout d’abord, il y a la question de l’adoption. Ensuite, il y a le problème de l’interface utilisateur, des erreurs faciles à commettre, ainsi que des listes de serveurs de clés désordonnées qui remontent à plusieurs années. Mais la vraie question est celle de la sécurité des clés à long terme. Une clé à long terme n’est aussi sûre que le plus petit dénominateur commun de vos pratiques de sécurité au cours de sa durée de vie. C’est le maillon faible.

Aucun ingénieur compétent en cryptographie ne concevrait un système qui ressemblerait à PGP aujourd’hui, ni ne tolérerait la plupart de ses défauts dans une autre application, relève⁸ le Blog de Latacora, soulignant sa complexité absurde, son design de couteau suisse faisant un tas de choses mais aucune correctement, son aspect embourbé dans la rétrocompatibilité, son authentification défaillante et une gestion des identités incohérente, des clés lourdingues, un code farfelu et des négociation hasardeuses entre des algos pléthoriques. Et de rajouter que PGP fait fuiter les métadonnées et est démuni de forward secrecy.

N’en jetez plus la coupe est… Ah, on continue?

L’email n’est pas sûr et ne peut pas être sécurisé. Les outils dont nous disposons aujourd’hui pour chiffrer les emails sont très imparfaits. Même si ces défauts étaient corrigés, l’email resterait dangereux. Il n’est pas possible de résoudre ces problèmes de manière satisfaisante répète⁹ le Blog de Latacora. Les métadonnées sont aussi importantes que le contenu et le courrier électronique les fait fuir. Tous les messages archivés finissent par fuir. Tout secret à long terme finit par être dévoilé.

Et pour couronner le tout, des divergences de standards PGP sont en train d’apparaître à la suite d’un schisme¹⁰ entre OpenPGP et GnuPG comme l’explique ArchLinux dans son Wiki¹¹:

Avertissement : GnuPG a débuté comme une implémentation du format OpenPGP. Cependant, ces dernières années, son mainteneur s’est activement écarté de l’effort de standardisation d’OpenPGP et étend séparément le format d’une manière spécifique à GnuPG (voir draft-koch-librepgp). Ces changements entraînent des problèmes de compatibilité avec d’autres implémentations depuis la version 2.4.

CQFD/QED, j’adhère et plussoie.

Désormais, je vais privilégier des protocoles qui garantissent la forward secrecy des communications sensibles, utiliser des clés courtes et solides en Ed25519/ChaCha20-Poly1305, à la durée de vie réduite, aux algorithmes récents et tant pis pour Quid de la rétro-compatibilité pour lire les vieux emails chiffrés en 2010.

Alternative à PGP

Chiffrer les emails

Don’t. Nope. Nada. Fini. J’ai dit non.

Contactez-moi par le moyen de votre choix (plaintext email, Matrix, XMPP) et je vous fournirai mon Signal username.

Signer des données/packages

Utilisez Minisign de Franck Denis, le type derrière Libsodium ou Signify par Ted Unangst, celui d’OpenBSD.

Chiffrer des fichiers/dossiers

Utilisez age encryption un outil de chiffrement simple écrit en Go, moderne et sécurisé avec des clés courtes et explicites (ChaCha20-Poly1305), pas d’options de configuration. Voir aussi Awesome age, un écosystème construit autour de age encryption (implémentations, plugins, CLI, GUI, outils).

Utilisez Tomb, un outil minimaliste en ligne de commande basé sur dm-crypt et LUKS (Linux Unified Key Setup) pour créer des containers à la Veracrypt.

Utilisez Picocrypt un tout petit utilitaire tout simple de chiffrement (XChaCha20 cipher et Argon2id pour la dérivation des clés) qui fonctionne sous Linux, macOS, Windows.

Transmettre des fichiers

Utilisez Magic Wormhole. Les clients Magic Wormhole utilisent la méthode password-authenticated key exchange (PAKE) pour chiffrer les fichiers transmis entre destinataires. C’est facile (du moins pour les nerds), sécurisé et cool (Android, iOS, desktop).

Utilisez le moyen de votre choix après avoir zippé et chiffré les données avec age encryption ou Picocrypt.

Chiffrer des sauvegardes

Utilisez BorgBackup, les données sont chiffrées côté client en 256-bit AES et l’intégrité et l’authenticité des données vérifiées à l’aide de HMAC-SHA256.

Chiffrer des données d’application

Utilisez la librairie d’applications libsodium. Voir aussi les projets utilisant libsodium.

Addendum

Il se peut que je conserve une clé PGP au cas où un irréductible des moyens de transmission électroniques décentralisés et libres (l’email en bref) qui soit et réfractaire à Signal et aux smartphone (si si, j’en connais) veuille ab-so-lu-ment me contacter en chiffré, mais je ne promets rien.