Base de connaissances

Chiffrement de bout en bout

Des clés OpenPGP créées dans votre navigateur. Le courrier que vous envoyez vers une autre adresse OpenEmail peut être scellé avant de quitter l'onglet, et le courrier scellé qui vous est adressé s'ouvre dans le volet de lecture, déchiffré sur votre machine. Les clés ne sont jamais les nôtres, donc jamais à remettre.

Détails

Les deux moitiés sont câblées de bout en bout. Rédiger vers un destinataire dont la clé est publiée scelle le corps dans le navigateur avant que la requête parte ; le serveur reçoit une armure qu'il ne peut pas lire, la marque pgp-mime et construit un véritable message multipart/encrypted. La lecture fonctionne à l'envers de la même façon : le texte chiffré est récupéré, déchiffré dans l'onglet, et rendu comme un courrier ordinaire.
L'algorithme est celui que tout le monde utilise déjà : OpenPGP, via openpgp.js, et PGP/MIME sur le fil. Une clé v4 sur Curve25519, la même forme que celle qu'émet Proton et que produit gpg avec son algorithme moderne par défaut. Le courrier que ceci lit est donc en principe le même que celui que produisent Thunderbird, gpg et Proton, et rien ici n'est un format à nous qu'il faudrait défaire plus tard.
En pratique, toutefois, c'est d'OpenEmail à OpenEmail. Il n'y a ni Web Key Directory, ni consultation de serveur de clés, ni analyse d'en-tête Autocrypt nulle part dans ce code : le seul endroit où la clé d'un destinataire est trouvée est notre propre annuaire, qui contient les clés publiées depuis cette application par des personnes dont l'adresse est sur un domaine hébergé ici. Il n'y a pas non plus de moyen de distribuer votre clé. L'application publie votre moitié publique dans cet annuaire et n'en propose ni copie ni export : un correspondant sous Thunderbird n'a donc aucun moyen pris en charge de l'obtenir. L'interopérabilité avec le monde PGP au sens large est une propriété du format, pas encore quelque chose que le produit fait pour vous.
La lecture n'est pas limitée de cette façon, car le déchiffrement n'a besoin d'aucun annuaire. Tout message PGP/MIME ou PGP en ligne qui parvient à cette boîte scellé vers une clé présente dans ce navigateur s'ouvre, quel qu'en soit l'expéditeur et quel que soit son client. Cela inclut les messages scellés vers une clé que vous avez depuis remplacée : les clés retirées restent dans le trousseau et sont essayées à côté de la clé courante, si bien qu'une rotation ne vous coûte pas le courrier déjà reçu.
Le vert veut dire ouvert, et il n'est accessible d'aucune autre façon. La ligne Détails → Sécurité ne passe au vert qu'après qu'un déchiffrement a réellement rendu du texte clair dans cet onglet, jamais à partir d'un champ du message, jamais du seul fait qu'une enveloppe chiffrée est arrivée. Elle indique « Chiffré de bout en bout. Ouvert avec votre clé dans ce navigateur ». Tout ce qui reste en deçà a sa propre phrase plutôt qu'une phrase commune : recherche en cours, clé verrouillée, scellé vers une clé que ce navigateur ne détient pas, impossible à ouvrir, aucune clé ici, et ce navigateur ne nous a pas laissés regarder. « Nous n'avons pas pu vérifier » et « vous n'avez pas la clé » sont deux affirmations différentes, et la ligne vous oblige à lire laquelle vous avez obtenue.
S/MIME reste impossible à ouvrir. C'est du CMS sous un certificat X.509, openpgp.js ne sait pas y toucher, et il n'existe aucun magasin de certificats dans le produit pour détenir la clé même s'il le pouvait : un message S/MIME indique donc qu'OpenEmail ne peut pas l'ouvrir, et ne se voit pas proposer un déverrouillage qui ne ferait rien.
La moitié privée est générée dans votre navigateur et n'en sort jamais : ni chiffrée, ni dans une sauvegarde, ni dans un outil d'assistance. Elle n'est jamais envoyée au serveur : il n'y a donc rien ici à remettre, à assigner ou à laisser fuiter. Elle est stockée verrouillée par phrase secrète dans une base IndexedDB qui lui est propre, openemail-keyring, délibérément hors de portée du conseil « videz votre cache » et de la réinitialisation de la console de débogage : les deux effacent le cache de requêtes, et une clé stockée à côté ferait qu'un conseil d'assistance banal détruirait définitivement tous les messages chiffrés que le compte a jamais reçus. Supprimer votre compte la supprime bel et bien, car le courrier part avec. Le déverrouillage la garde en mémoire pendant 15 minutes d'inactivité et 8 heures au maximum, après quoi la lecture du message scellé suivant redemande la phrase secrète.
Il n'y a ni séquestre ni récupération, et c'est définitif plutôt que non construit. Votre phrase secrète est la seule entrée ; oubliez-la et chaque message que quiconque vous a scellé reste sur nos serveurs sous forme de texte chiffré que personne ne peut lire, nous compris. Le courrier est perdu, et aucune insistance ne le récupère. L'écran d'inscription le dit avant que la première clé existe, derrière une case que vous devez cocher, le fichier de sauvegarde est obligatoire, et le bouton Terminé reste désactivé tant que vous ne l'avez pas téléchargé. Ce fichier est écrit sans le durcissement supplémentaire au repos qu'emploie ce navigateur, exprès, pour qu'il s'importe encore dans des versions plus anciennes de gpg : une sauvegarde que vous ne pouvez pas ouvrir ailleurs n'est pas une sauvegarde. La clé vit en outre dans un seul navigateur sur un seul appareil, et un téléphone ou un deuxième portable n'a rien tant que vous n'y avez pas importé ce fichier.
L'annuaire ne contient que des clés publiques et rien d'autre, et une clé appartient à une personne plutôt qu'à une boîte aux lettres, puisqu'une clé attachée à une adresse devrait être copiée chez tous ceux avec qui cette adresse est partagée, ce qui est du séquestre sous un autre nom. Une consultation exige une session connectée et l'autorisation d'envoyer, jamais un point d'accès public, car un sondage d'adresses ouvert est un oracle qui dit à n'importe qui quelles adresses sont des boîtes actives ici. Il répond de façon identique à « nous n'hébergeons pas cela » et à « nous l'hébergeons et personne n'a publié de clé », puisque distinguer les deux ne ferait que déplacer l'oracle derrière une authentification au lieu de le supprimer. Et une clé cesse d'être distribuée dès que son propriétaire perd l'accès à l'adresse, plutôt que quand quelqu'un pense à la révoquer.
Chaque octet est scellé dans le navigateur au moment où vous l'écrivez, et c'est ce qui rend les envois différés possibles : un message planifié ou en attente dans la fenêtre d'annulation est stocké sous forme de texte chiffré et expédié plus tard par une file qui ne détient aucune clé et n'en peut rien lire. Un destinataire dont la consultation d'annuaire a ÉCHOUÉ bloque l'envoi au lieu d'être traité en silence comme n'ayant pas de clé. Et un message scellé ne part jamais que par un chemin qui transporte un message entier. Un chemin sortant qui prendrait un corps HTML à la place publierait l'armure comme texte visible et signalerait un succès : un envoi qui atterrirait là est donc refusé avant qu'un octet parte, plutôt qu'après.
Ce que le scellement coûtera, mesuré plutôt que deviné : l'armure pèse environ 1,86 fois les octets bruts, si bien qu'environ 2,7 Mo de pièces jointes tiennent dans les 5 Mo qu'autorise le chemin d'envoi, et le compositeur refuse une charge supérieure avant de passer des secondes à en chiffrer une que le transport rejetterait. Le courrier chiffré ne rapporte ni ouvertures ni clics, car le suivi par destinataire fonctionne en faisant varier le corps selon la personne et qu'un unique bloc scellé ne peut pas varier, et parce qu'un lien réécrit est un lien que nous pouvons lire, soit l'inverse de la promesse. Un envoi chiffré ne peut jamais non plus être dédoublonné par une clé d'idempotence : une clé de session neuve rend le texte chiffré différent à chaque tentative, si bien qu'une reprise ne porte jamais la même empreinte que l'original.
La planification scelle au moment de la rédaction, pas au moment de l'envoi. Le compositeur construit le texte chiffré contre les clés que détiennent ses destinataires le jour où vous écrivez, pas le jour où le message partirait, la règle que ce produit applique déjà aux modèles et aux traductions, où un message planifié porte ce que vous avez approuvé plutôt que ce qui a changé depuis. La différence, c'est qu'un modèle périmé est seulement dépassé alors qu'une clé périmée est illisible : le compositeur nomme donc la date en toutes lettres plutôt que de proposer une réserve : « Scellé maintenant, envoyé le …. Chaque destinataire aura besoin de la clé qu'il détient aujourd'hui. » Le refus qui garde l'autre moitié est en place mais ne s'est jamais déclenché, car un tel message ne peut pas encore exister : s'il existait, le modifier ensuite serait refusé plutôt que discrètement autorisé, puisque corriger le corps écrirait du texte clair par-dessus le texte chiffré et changer les destinataires changerait ceux à qui il a été scellé, et l'un comme l'autre livrerait en clair pendant que tous les écrans continueraient de le dire chiffré.
Deux choses que le compositeur ne proposera pas du tout, et il le dit au lieu d'échouer au moment de l'envoi. Un modèle est rendu sur le serveur à partir d'une version publiée : il n'y a donc rien à sceller dans ce navigateur. Une réponse cite la conversation en dessous d'elle et cette citation est ajoutée après le moment où le corps serait scellé, ce qui laisserait une copie lisible de tout le fil en dehors du sceau ; les réponses et les transferts ne peuvent donc pas être chiffrés tant que l'historique cité n'est pas replié à l'intérieur du texte chiffré.
Rien de tout cela ne cache votre ligne d'objet, à qui vous avez écrit, ni quand. L'objet voyage en clair sur un message scellé exactement comme sur n'importe quel autre, et le volet de lecture le dit sur le message lui-même : « L'objet et les adresses ont voyagé en clair ; ce texte, non. » PGP couvre le corps et aucune de ses implémentations ne couvre le reste. Les brouillons ne sont pas scellés non plus, car l'enregistrement automatique continue d'écrire du texte clair dans votre boîte pendant que vous rédigez, parce que ne pas enregistrer en silence ferait perdre du travail, et le cadenas le dit en toutes lettres.
Reconnaître le courrier qui arrive scellé est venu en premier et tient toujours. PGP/MIME, l'armure PGP en ligne et S/MIME s'affichaient autrefois comme un corps vide accompagné de deux pièces jointes dénuées de sens, parce que l'analyseur ne traite comme lisibles que le texte brut et le HTML et laissait tomber le reste dans la bande des fichiers. Ces parties sont désormais identifiées, le mobilier du protocole est tenu hors de la liste des pièces jointes, le texte chiffré est stocké intact, ce à partir de quoi le lecteur déchiffre plutôt que d'aller rechercher quoi que ce soit, et un message que personne ici ne peut ouvrir le dit encore clairement.
Un message signé est traité comme une chose à part, parce qu'il en est une. Son corps est lisible : la recherche, les règles et tout le reste continuent donc de fonctionner dessus ; il n'est jamais mis derrière un verrou ni passé par un déchiffrement. La ligne indique « Signé par l'expéditeur. Signature non vérifiée », en grisé, et elle reste grisée tant que rien ici ne sait réellement vérifier une signature, ce que rien ne fait encore, y compris sur un message déchiffré avec succès. Voir qu'un message est scellé n'est pas la même chose que l'avoir ouvert, et l'ouvrir n'est pas la même chose que savoir qui l'a scellé.
Sur un message chiffré, le corps est retenu à tout ce qui le lirait autrement : l'extrait de recherche, la passe sur le corps du détecteur de hameçonnage, le contrôle d'écriture par IA, les conditions portant sur le corps dans les règles, l'import des invitations d'agenda et les résumés de fil. La moitié authentification du contrôle anti-hameçonnage tourne toujours, car DMARC, DKIM et SPF se lisent sur des en-têtes que le texte chiffré ne cache pas. Le déchiffrement n'y change rien. Le texte clair n'existe que dans l'onglet qui l'a ouvert : un message scellé reste donc introuvable par la recherche et reste hors des fonctions d'IA même après votre lecture, et la traduction n'est pas proposée dessus. C'est le prix de la promesse, pas un oubli.