gouttegd a écrit 1805 commentaires

Oh fais pas semblant de pas comprendre. Je parle d’une boîte spam auquel le destinataire a accès, bien évidemment — dans laquelle il peut vérifier la présence d’éventuels faux-positifs.

Ce n’est pas ce qui se passe dans le cas reporté dans le journal, qui mentionne clairement que les messages concernés n’arrivent ni dans la boîte de réception normale, ni dans la boîte « courriers indésirables ».

Il faut une grosse dose de mauvaise foi pour affirmer qu’un message dont le destinataire n’a aucun moyen de prendre connaissance, même en allant consulter le dossier « courriers indésirables », a bien été « délivré ».

Trouve-moi dans le standard le passage qui dit que le serveur qui a répondu 250 est autorisé à ne délivrer le message que si certaines conditions supplémentaires, au bon vouloir du serveur, sont remplies — et à ne pas prévenir l’émetteur si le serveur décide que non, finalement il ne délivrera pas le message.

Ça ne stipule en aucun cas dans quelle boite/dossier/buffer ça atterrit

Où ai-je-dit le contraire ? J’ai explicitement dit que délivrer le message dans une boîte spam était acceptable.

Le protocole SMTP ne gère que l'échange, ce qui se passe après, c'est chacun sa cuisine.

Non. Le standard SMTP dit clairement que lorsque le serveur répond 250 à une soumission de message, il s’engage à délivrer ce message dans la boîte du destinataire, ou à signaler à l’émetteur que la délivrance n’a pas été possible le cas échéant.

Accepter un message en disant « tout va bien » alors qu’on l’envoie direct à la poubelle, sans aucune possibilité¹ pour le destinataire d’en prendre connaissance et sans jamais avertir l’émetteur, est une violation flagrante du protocole.

---

¹ Délivrer un message accepté dans une boîte « spam » à part, plutôt que dans la boîte de réception » normale » du destinataire, reste acceptable.

Si tu est motivé, tu peux essayer de suivre toutes les recommandations de Microsoft pour assurer la délivrance des messages, comme participer au Junk Email Reporting Program ou t’inscrire au Smart Network Data Services.

D’expérience, ça aide un peu mais ça n’est pas suffisant. Je soupçonne fortement que la silver bullet qui garantira que tous tes messages arrivent est de payer pour la certification Return Path (dont le prix ne semble plus être disponible en ligne, mais à l’époque où j’avais vérifié je crois que c’était de l’ordre de $250 par an).

(Je ne mettrais pas de lien vers Return Path parce que je ne cautionne pas cette pratique qui me semble ouvertement mafieuse — « c’est un joli serveur mail que vous avez là, ce serait dommage que ses messages se perdent. »)

J’admets que j’ai zappé le fait que la question était posée dans le forum linux-débutant. Néamnoins :

• l’auteur du message fait montre d’une certaine volonté de comprendre ;
• c’est une nouvelle machine, a priori sans encore de données personnelles dessus, donc si l’auteur veut apprendre une manière flexible de gérer les volumes c’est le bon moment pour le faire (plutôt qu’au bout de six mois).

tu lui proposes de réinstaller lui-même le système d'exploitation

Ce qu’il n’aurait besoin de faire qu’une seule et unique fois, même s’il découvre a posteriori qu’il a besoin de changer la manière dont il utilise ses disques.

(J’ai une machine que j’ai mise en place il y a plus de dix ans. Elle n’a plus aucun des disques durs d’origine, ils ont tous été remplacés au moins une fois. Je n’ai jamais réinstallé le système d’exploitation.)

Je trouve la proposition d'une partition DATA bien plus raisonnable.

À court terme, peut-être. Jusqu’au jour où ça ne conviendra plus, et où il sera impossible de modifier quoi que ce soit sans devoir préalablement bouger les données accumulées sur la partition.

Après, que je sache je ne mets pas un flingue sur la tempe de tisaac. Je lui propose une manière de gérer ses disques qui soit flexible et qui ne date pas des années 1990. Après, il fait ce qu’il veut.

Tu fais comme tu veux, mais moi personnellement je ne garderai rien du partitionnement actuel, parce qu’il y a au moins deux choses qui me chagrinent :

• des tables de partitions DOS plutôt que GPT, ce qui à mon sens ne se justifie pas du tout en 2020 ;
• surtout, pas d’utilisation de LVM, d’où un énorme manque de flexibilité.

Du coup, moi ce que je ferais, c’est :

• partitionner /dev/sda comme suit :
  • /dev/sda1: une petite partition (~128 ou 256 MB) pour EFI ;
  • /dev/sda2: tout le reste du disque ;
• créer une partition unique sur /dev/sdb couvrant tout le disque ;
• créer un groupe LVM contenant /dev/sda2 et /dev/sdb1 comme volumes physiques ;
• créer autant de volumes logiques que nécessaires et les affecter aux volumes physiques comme tu veux.

Par exemple, si tu veux avoir les fichiers du système sur le SSD et tes données sur le HDD, tu peux avoir un volume logique pour la racine que tu affectes au SSD et un autre volume logique pour /home que tu affectes au HDD.

L’avantage de LVM étant que tu pourras changer tout ça à ta guise sans jamais avoir besoin de toucher aux partitions physiques ou de réinstaller quoi que ce soit.

Le mieux (ou du moins le plus rapide pour moi…) est que je te renvoie vers mon blog, où j’ai expliqué pourquoi je ne cache pas mon adresse et comment je gère le spam.

Ces billets datent de 2012, mais sont toujours valables aujourd’hui, seuls quelques détails techniques ont changé — par exemple j’utilise maintenant pypolicyd-spf au lieu de tumgreyspf pour la validation SPF), et un script Sieve au lieu de procmail pour envoyer les messages dans la boîte spam.

Le point important est que, hors les messages invalidés par SPF (que je n’ai aucun scrupule à rejeter d’entrée sans jamais les voir, dès lors que la politique SPF du domaine émetteur l’autorise), tous les messages marqués comme étant probablement des spams arrivent quand même jusqu’à une boîte mail sur ma machine, que je peux consulter de temps à autres (je fais typiquement ça une fois par jour) et ainsi vérifier qu’il n’y a pas de faux positifs. C’est pour ça que je dis qu’un message envoyé à mon adresse me parviendra toujours — au pire je mettrais un ou deux jours à le voir s’il a été classé comme spam par erreur, mais je finirai par le voir quand même. Le serveur ne prend aucune décision définitive à ma place — contrairement à ce que font certains fournisseurs qui ont la main lourde en la matière…

Est-ce que tu reçois beaucoup de spam du coup ?

En gros, une dizaine de spams rejetés par jour par SPF, et à peu près autant de messages marqués comme « spam probable » — et qui sont systématiquement bel et bien des spams, les faux positifs étant en fait virtuellement inexistants (j’en ai eu en tout et pour tout quatre depuis que j’ai mis en place mon filtre, le dernier remontant à 2013).

La clef RSA générée est générée par la puce TPM, ce qui peut être problématique car le générateur d'aléa du TPM n'est pas auditable (et les histoires de générateurs d'aléa troués sont légion).

En effet, et les puces Infineon n’ont pas été épargnées d’ailleurs.

Est-ce possible de générer sa propre clef, en dehors du TPM, typiquement avec ssh-keygen ou gnupg, pour ensuite la protéger avec le TPM de sorte qu'elle ne soit utilisable que par le TPM ?

En théorie oui, mais le support pour ce cas d’utilisation semble limité voire franchement manquant.

Comment ça se passe si une clef est valable pour plusieurs mails sur des domaines distincts ?

Il faut faire la manip pour tous les domaines le supportant ?

Oui. L’annuaire d’un domaine distribue les clefs de ce domaine, et de ce domaine seulement.

L’idée derrière WKD est que si Alice a déjà choisi de confier ses e-mails à l’opérateur de example.org, il n’est pas déraisonnable de lui confier aussi le soin de diffuser sa clef (Alice restant bien sûr libre de diffuser sa clef elle-même à côté, par tous les moyens à sa disposition).

Mais il n’y a aucune raison pour que example.org se mette à diffuser les clefs associées à des adresses en example.com.

Si la clef d’Alice contient une adresse en example.org et une en example.com, quand elle soumet sa clef à l’annuaire de example.org elle envoie une version de la clef ne contenant que l’adresse en example.org (et même si de son côté elle envoyait la clef complète, côté serveur la clef est filtrée à la réception pour supprimer toutes les adresses ne correspondant pas au domaine).

Dans mon cas, je n'en ai pas beaucoup, donc ce n'est pas forcément si pénible

Je n’ai pas testé, mais je suppose que l’implémentation d’Enigmail tente automatiquement de soumettre la clef aux annuaires de tous les domaines dans lesquels la clef a des adresses, lorsque tu sélectionnes la commande Upload to your provider’s Web Key Directory.

Si tu soumets ta clef toi-même avec gpg-wks-client, alors oui, tu dois répéter la procédure pour chaque adresse.

Ooh, pan sur le bec ! C’est une erreur de ma part, désolé.

La commande --send-keys attend un « identifiant de clef », pas un « identifiant utilisateur » comme je l’ai écrit.

Un identifiant de clef (key ID) peut être : les 4 derniers octets de l’empreinte de la clef (short key ID), les 8 derniers octets de l’empreinte (long key ID), ou l’empreinte entière.

Dans les exemples du journal, la clef d’Alice a pour empreinte 7685DC4214D727BB011BD6B754B4CC7749CAE7C3 (gpg -k alice@example.org pour afficher l’empreinte), et donc pour identifiant court 49CAE7C3 ou pour identifiant long 54B4CC7749CAE7C3. C’est l’une de ces trois valeurs qu’il faut passer comme argument à --send-keys, à la place de alice@example.org.

Il faut au minimum une sous-clef de chiffrement associée.

Enfin, « il faut » : non, pas vraiment. Si tu sais que tu ne vas jamais utiliser OpenPGP que pour signer (par exemple, cas d’un développeur de logiciels libres qui signe ses commits ou ses release tarballs), tu peux parfaitement te passer d’une sous-clef de chiffrement.

Compte tenu de tous problèmes occasionnés par ces pratiques (pas seulement vis-vis de Git comme c’est le cas ici ; ces pratiques sont aussi une des raisons pour lesquelles DKIM et listes de discussion ne font pas toujours bon ménage), le bénéfice me semble minime.

Je suis pour ma part convaincu que ces pratiques subsistent davantage par conservatisme (« on a toujours fait comme ça ») que parce qu’elles ont une réelle utilité.

On peut agree to disagree sur ce point.

Fun fact : tu reçois aussi ces demandes de désabonnement sur les listes où le lien de désabonnement est ajouté à chaque message…

Les sous-clefs ont été introduites par PGP 5 (RFC 2440) pour plusieurs raisons, la principale étant le besoin de séparer les clefs de signature des clefs de chiffrement.

Cette séparation était elle-même motivée par plusieurs considérations :

• Tous les algorithmes de cryptographie asymétrique ne permettent pas forcément d’utiliser une même paire de clefs pour à la fois signer et chiffrer. RSA le permet (on chiffre avec la clef publique, on signe avec la clef privée), mais en fait c’est l’un des seuls (en fait parmi les algorithmes disponibles dans OpenPGP c’est le seul). Une clef DSA ne peut servir qu’à signer, une clef ElGamal ne peut servir qu’à chiffrer.

• Même quand il est possible d’utiliser une même paire pour signer et chiffrer (avec RSA donc), les cryptologues ne voient pas ça comme une bonne idée, ça peut entr’ouvrir la porte à certaines attaques, au moins théoriquement.

• Certains pays ont passé des lois obligeant à la remise des clefs de chiffrement sous injonction judiciaire (notamment le Regulation of Investigatory Powers Act au Royaume-Uni). Séparer les clefs de signature des clefs de chiffrement permettait de ne remettre aux autorités que ces dernières, sans compromettre les clefs de signature.

Un autre avantage des sous-clefs est de permettre une rotation plus facile des clefs, puisqu’on peut changer de sous-clef de manière transparente pour les correspondants (contrairement à la clef principale).

Faut-il en avoir ou est-ce facultatif ? Est-ce automatique ?

La clef principale est une clef de signature. Il faut au minimum une sous-clef de chiffrement associée. GnuPG en génère une automatiquement.

La plupart des utilisateurs n’ont pas besoin de s’en soucier davantage. Il y a des raisons valables de vouloir d’autres sous-clefs, mais ça les fait basculer du côté obscur des utilisateurs « avancés ».

penses-tu qu'apprendre à git-am à traiter ce genre de message serait la bonne solution ?

Clairement, oui. Mais à mon avis il y a peu de chance que ça arrive. Le commentaire ci-dessus ne témoigne pas d’un très grand enthousiasme des développeurs de Git pour MIME…

Enfin, ça ressemble plus à un hack qu'autre chose

Pas vraiment, c’est une utilisation parfaitement légitime des conteneurs MIME.¹

Bien sûr, la « bonne » solution serait de corriger les softs de gestion de ML pour qu'ils ne touchent pas les messages signés, mais je pense que c'est une bataille déjà perdue d'avance.

Non. Les logiciels de liste de discussion peuvent déjà être configurés pour relayer les messages sans les modifier (par exemple, ne pas ajouter de pied de page, ou ne pas rajouter un préfixe [NOM_DE_LA_LISTE] dans le champ d’objet). Ce qu’il faudrait corriger, c’est l’opinion des administrateurs de listes qui pensent que de telles modifications sont des « fonctionnalités » incontournables des listes de discussion. Et ça, ça ne se corrige pas aussi facilement qu’un bug dans un logiciel. ^{^}

---

¹ À la décharge des développeurs de Git : ils ne sont pas les seuls à ne pas supporter les structures MIME complexes. Le format MIME autorise une grande complexité (on peut imbriquer les structures autant qu’on veut), mais beaucoup de clients e-mail ne supportent qu’un sous-ensemble des structures possibles.

qu'est-ce qui te fait croire en la sécurisation possible de l'e-mail

Outre le fait que « GnuPG le fait bien », ce qui me rend optimiste est l’activité autour d’OpenPGP.

Ce n’est pas forcément encore visible pour l’utilisateur, mais il y a eu des apports significatifs depuis quelques années. Pêle-mêle et sans prétendre être exhaustif :

• deux nouveaux protocoles de distribution des clefs :
  • distribution via le DNS, par Paul Wouters (DANE OPENPGP) ;
  • protocole Web Key Directory, par Werner Koch ;
• un nouveau modèle de confiance, trust-on-first-use, par Neal Walfield ;
• de nouvelles implémentations :
  • RNP (Ronald Tse) ;
  • Sequoia-PGP (Vincent Breitmoser, Justus Winter) ;
• la future prise en charge native d’OpenPGP par Thunderbird¹ (Patrick Brunschwig)
• un profil d’utilisation d’OpenPGP pour le chiffrement opportuniste, Autocrypt (Daniel Kahn Gilmor, Vincent Breitmoser) (probablement un truc que je devrais présenter dans un journal, d’ailleurs) ;
• un nouveau logiciel serveur de clefs, Hagrid² (Vincent Breitmoser)
• une révision du standard dans les tuyaux³ (toutes les personnes déjà mentionnées, plus quelques autres).

---

¹ J’ai des réserves sur la manière dont cette prise en charge est amenée, comme mentionné dans le journal, mais fondalement c’est quand même une bonne nouvelle.
² Idem. J’ai des réserves sur certains comportements de Hagrid et sur le principe d’un serveur centralisé comme keys.openpgp.org, mais j’accueille favorablement toute initiative faisant avancer OpenPGP, et Hagrid en est une.
³ Certes, l’élaboration du RFC 4880bis aura été beaucoup plus longue que prévu — le plan était de sortir le RFC pour 2017 au plus tard…

pourquoi, si c'est pas indiscret ?

En gros, parce que les listes de discussion ont des traditions douteuses qui persistent aujourd’hui et que Git a un support seulement minimaliste du format MIME.

…

D’accord, j’explique.

J’envoie des patchs sur une liste de discussion qui, comme (malheureusement) beaucoup de listes, juge utile de modifier les messages pour ajouter un footer contenant des informations sur la liste elle-même (typiquement un lien vers les archives de la liste sur le web, et un lien vers un formulaire de désinscription).

C’est-à-dire que j’envoie un message constitué d’une seule part MIME (contenant le patch précédé du message de commit), et il est transformé par le logiciel de la liste de discussion en un message avec la structure suivante :

• multipart/mixed (conteneur MIME)
  • text/plain (corps du message original, contenant le patch)
  • text/plain (« pied de page » de la liste de discussion)

Pour l’instant, pas de problème : git am est capable de comprendre cette structure et d’extraire le patch de la part MIME qui le contient.

Quand on signe un e-mail au format PGP/MIME, le mail résultant a la structure suivante :

• multipart/signed (conteneur MIME)
  • text/plain (corps du message original)
  • application/pgp-signature (signature)

Là encore, pas de problème pour l’instant, git am peut gérer ça.

Le problème survient quand on envoie un tel message sur une liste de discussion qui rajoute un pied de page. Parce que là, le message final ressemble alors à ça :

• multipart/mixed (conteneur MIME)
  • multipart/signed (conteneur MIME)
  • – text/plain (corps du message original, contenant le patch)
  • – application/pgp-signature (signature)
  • text/plain (pied de page de la liste de discussion)

Et ça, c’est une structure que git am ne comprend pas et dont il est incapable d’extraire le patch. Du coup, ça casse le workflow du développeur upstream et augmente considérablement le risque que le patch ne soit purement et simplement ignoré.

Le problème ne vient pas du message lui-même. Cette structure à plusieurs niveaux est une structure MIME parfaitement valide. C’est Git qui ne gère pas les conteneurs MIME imbriqués. Globalement, Git a un support très réduit de MIME, comme ses développeurs le reconnaissent ouvertement dans ce commentaire (mailinfo.c, lignes 213–216) :

/* NOTE NOTE NOTE.  We do not claim we do full MIME.  We just attempt
 * to have enough heuristics to grok MIME encoded patches often found
 * on our mailing lists.  For example, we do not even treat header lines
 * case insensitively.
 */

Si ce n'est pas trop velu, mon serveur mail apprendra à distribuer des clés dans les jours qui viennent ;)

Pour info, je prépare un journal là-dessus.

(Ça se voit un peu, que je m’emmer… m’ennuie pendant le confinement, ou pas du tout ?)

Je suis tombé il n'y a pas longtemps sur mime-construct qui est un script perl qui peut permettre de faire ça

J’ai aussi commis un truc du même genre, quoique pas aussi générique.

Une des raisons était de pouvoir envoyer des patchs par e-mail signés, ce que git send-email ne permet pas. Mon programme me permettait de faire ça :

$ git format-patch ...
$ fmail -s < 0001-mycommit.patch > 0001-mycommit.patch.signed
$ git send-email 0001-mycommit.patch.signed

(Mais c’était une mauvaise idée en fin de compte.)

Par curiosité, pourrais-tu présenter les arguments qui t'incitent à continuer dans la voie d'essayer de sécuriser l'e-mail ?

En gros, je suis convaincu que ça en vaut toujours la peine. Je pense que l’e-mail n’est pas prêt de disparaître, même si ça fait au moins quinze ans qu’on prédit le contraire.

Aucune des alternatives, y compris celles présentées comme des « e-mail killers » n’offre les mêmes caractéristiques, comme :

• la décentralisation (incluant la possibilité pour quiconque d’être son propre fournisseur tout en interopérant avec le reste du monde) ;
• la bidouillabilité (incluant le fait qu’on peut exploiter l’e-mail pour des usages pour lesquels il n’était pas du tout prévu) ;
• le côté « je peux joindre n’importe qui n’importe où dans le monde du moment que j’ai son adresse e-mail ».

Les détracteurs de l’e-mail diront que ces caractéristiques sont des points faibles. La décentralisation est une des raisons pour lesquelles l’e-mail est difficile à sécuriser (c’est toujours plus facile quand on est le seul joueur autour de la table, hein Signal ?), la bidouillabilité a probablement pas mal à voir avec la complexité de l’e-mail aujourd’hui (on bidouille, on bidouille, et avant qu’on s’en rende compte on a monté une usine à gaz), et la possibilité d’envoyer un mail à quiconque, même sans aucun contact préalable, est ce qui nous a donné le spam.

Ces critiques sont valables, l’e-mail a les défauts de ses qualités. Mais dans la balance, pour moi les défauts de l’e-mail sont largement acceptables au vu de ses avantages. Et je ne dois pas être tout-à-fait le seul à penser ça vu qu’en quinze ans, aucun des « e-mail killers » auto-proclamés n’a réussi à s’imposer comme le remplaçant des e-mails.

Mais sérieusement, est-ce que vous vous rendez compte à quel point ça peut être imbitable pour des utilisateurs pas à l'aise avec l'outil informatique?

À ton avis ? Tu crois que j’écrirais des articles de 50 000 signes, dans lequel je prends la peine d’expliquer les choses autant que possible, si je pensais qu’OpenPGP était abordable par tout un chacun sans efforts ?

Je suis parfaitement conscient qu’utiliser OpenPGP est plus difficile qu’on ne le voudrait. Toute la communauté OpenPGP en est consciente — en dépit de l’image tenace selon laquelle les développeurs et utilisateurs d’OpenPGP sont des vieux barbus élitistes perchés en haut de leur tour d’ivoire, s’amusant des déboires des noobs…

Il y a des efforts en cours (et depuis pas mal de temps) pour faciliter l’utilisation d’OpenPGP. Par contre, désolé (non), mais on ne rendra jamais OpenPGP aussi facile à utiliser que Signal & Co. D’une part parce que sécuriser l’e-mail est un problème difficile (tellement difficile que beaucoup de cryptologues ont purement abandonné cette idée et disent aujourd’hui « utilisez Signal »), mais aussi et surtout parce qu’un des intérêts d’OpenPGP en général et de GnuPG en particulier est de donner le contrôle aux utilisateurs (empowering the users, comme on dit en anglais), ce que les approches à la Signal ne font pas.

Du coup, oui, l’utilisateur d’OpenPGP aura toujours un certain apprentissage à faire. Et après ?

Allez, l’analogie foireuse du jour : ceux qui n’ont pas envie d’apprendre à cuisiner peuvent se contenter de télécharger Deliveroo, Uber Eats ou je ne sais quoi et se faire livrer des plats tout prêt (ou aller au restaurant, ou acheter des plats micro-ondables etc.). Est-ce que ça rend obsolète les batteries de cuisine ou les livres de recettes ? Les gens ne devraient pas avoir la possibilité de se faire leurs propres plats s’ils le souhaitent ?

Question bête mais: pourquoi les serveurs mails ne gèrent-ils pas la distribution des clés?
Si je veux la clé publique de toto@tartempion.fr, le serveur mail tartempion.fr devrait offrir la clé publique de toto si elle existe et si toto le souhaite.

Oh, un yakafocon !

Oui, la distribution des clefs par les fournisseurs de de messagerie seraient une très bonne idée. C’est une idée poussée par les développeurs de GnuPG justement, avec le protocole WKD qui est précisément conçu pour ça.

Maintenant si tu as une idée pour convaincre les fournisseurs de messagerie de mettre en œuvre ce protocole, on t’écoute. Je le fais sur mon propre serveur, posteo.de le fait, plusieurs serveurs gérés par des projets libres le font, mais au-delà ? Que dalle, y compris et surtout parmi les « gros » fournisseurs. (Se pourrait-il que ces gros brasseurs d’informations personnelles n’aient pas à cœur la vie privée de leurs utilisateurs ? Nooon, je ne puis le croire.)

Il y en a une copie complète sur une clef USB qui reste chez moi, plus des fragments réparties sur plusieurs supports (pas avec ssss, mais avec gfsecret, un outil que j’ai déjà présenté ici — et dont j’ai d’ailleurs appris en ce début d’année qu’il avait trouvé son chemin vers les dépôts Debian).

Y a-t-il un moyen de sauvegarder cette clé KEY_0 ?

Non, sauf à ce qu’il y ait un gros bug dans l’implémentation du TPM. Ce n’est pas supposé être possible.

Peut-on sauvegarder les clés "utilisateur" d'une autre manière ?

Les clefs « utilisateurs » sont sauvegardables comme n’importe quel fichier mais elles ne seront jamais utilisables qu’avec le TPM pour lequel elles ont été générées.

La meilleure option est de ne jamais faire en sorte qu’une clef liée à un TPM soit la seule clef SSH autorisée à se connecter à un serveur — c’est-à-dire, avoir une clef de sauvegarde comme dit flan ci-dessus. Sur toutes mes machines, j’autorise en plus de la clef que j’utilise tous les jours (et qui est lié au TPM de mon portable) une clef SSH « classique » (générée avec ssh-keygen et non liée à un quelconque matériel) stockée à l’abri sur un support hors-ligne.

Quelle est la durée de vie du TPM ?

Aucune idée. Dépend du modèle je suppose.

Il est pris automatique comme source d'entropie par le noyau ?

Pas à ma connaissance. Par contre, c’est une des sources d’entropie possible pour alimenter le périphérique /dev/hwrng, comme on peut le voir dans /sys/class/misc/hw_random :

# cat /sys/class/misc/hw_random/rng_available
tpm-rng-0 via

Et sur ma machine c’est la source actuellement utilisée :

# cat /sys/class/misc/hw_random/rng_current
tpm-rng-0

Donc lire depuis /dev/hwrng va directement taper dans le TPM, sans avoir besoin de passer par OpenSSL.

Si on veut utiliser cette source pour alimenter le pool d’entropie du noyau (celui qui est derrière les périphériques /dev/(u)random ou l’appel getrandom(2)), on peut utiliser des outils comme rngd(8).

je présume qu'il n'est impossible de sortir la clef privée. Donc le document chiffré est indéchiffrable ailleurs.

Oui, c’est tout le but.

le problème du ssh-agent/gpg-agent est traité depuis des années avec des solutions diverses : mes essais du jour, sous Debian/Buster n'ont pas été concluants : j'ai toujours un agent ssh qui se lance :(:(

Le problème de l’agent SSH qui démarre alors que tu ne le veux pas, c’est malheureusement hors de portée de GnuPG, c’est plutôt au niveau du système (de la distribution) que ça se passe.

Je n’utilise pas assez Debian pour être d’une grande aide, mais ce serait un bon début d’identifier quel agent se lance : est-ce que c’est le ssh-agent fourni avec OpenSSH, ou est-ce que c’est cette plaie de GNOME Keyring Manager ?

Si c’est le GNOME Keyring Manager, il est probablement lancé par un fichier gnome-keyring-ssh.desktop dans /etc/xdg/autostart. Si c’est le cas, tu peux le désactiver en « surchargeant » ce fichier, en plaçant un fichier avec le même nom dans ton $XDG_CONFIG_HOME/autostart et contenant ;

[Desktop Entry]
Type=Application
Name=SSH Key Agent
Hidden=true

(Peut-être que GNOME fournit un outil graphique permettant de configurer ce genre de choses sans avoir à manipuler les fichiers .desktop soi-même. Oh pardon, je viens de réaliser que j’ai écrit « GNOME » et « configurer » dans la même phrase, je ne sais pas ce qui m’a pris.)

Cela dit, au pire, même si un agent SSH non-désiré continue à se lancer, dans le fond ce n’est pas grave, l’essentiel est que SSH contacte bien l’agent GnuPG et pas un autre. Et pour ça, normalement la seule chose à faire est de définir la variable SSH_AUTH_SOCK pour qu’elle pointe vers la socket de l’agent GnuPG et non vers celle du GNOME Keyring Manager, en ajoutant la ligne suivante dans un script exécuté au démarrage de la session graphique (p.ex ~/.xprofile) ou au pire au démarrage d’un shell (p.ex ~/.bashrc) :

export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)

En gros peu importe comment, mais il faut que $SSH_AUTH_SOCK pointe vers /var/run/user/<uid>/gnupg/S.gpg-agent.ssh et non vers la socket de n’importe quel autre agent ta distribution ou ton environnement de bureau a cru bon de démarrer.