Chiffrement de bout en bout, avec les clés sur tes propres appareils

Il y a un secret à la racine de ton compte, et il est créé sur un appareil — pas délivré par un serveur. Tout le reste en est dérivé par un arbre de clés : une racine HMAC-SHA-512, puis une étape HMAC par élément de chemin étiqueté. La paire de clés qui ouvre les clés de session scellées sort de cet arbre sous le label "content", et il en va de même pour une clé distincte par type de blob stocké, de sorte qu’aucune clé ne fait deux métiers.

C’est pour ça qu’un navigateur tout neuf peut se connecter à ton compte sans rien te montrer de la semaine dernière. Se connecter prouve qui tu es auprès du relay. Lire une ancienne session demande la clé, et la clé n’est pas sur le relay pour être envoyée. Restaurer l’appareil, c’est l’étape qui la déplace — depuis un appareil qui l’a déjà, ou depuis la clé secrète que tu as conservée.

Cela signifie aussi que le cas de perte est réel et mérite d’être énoncé une fois : si tous les appareils connectés ont disparu et que la clé secrète a disparu avec eux, les sessions chiffrées ne peuvent être récupérées ni par nous ni par personne. Un relay capable de les restituer serait un relay capable de les lire.

Ajouter un appareil, c’est le moment où le matériel cryptographique se déplace : c’est donc le moment qui mérite d’être compris. Scanner le QR code lève une demande, et c’est tout ce que ça fait : l’approbation a lieu sur un appareil déjà connecté, et quand les deux écrans affichent un court code de confirmation, tu es censé les comparer avant d’approuver.

Ce que fait réellement l’approbation, c’est sceller la clé de contenu avec la clé publique de l’appareil demandeur, dans une enveloppe portant une clé d’émetteur éphémère et un nonce neuf. Cette enveloppe traverse le relay comme tout le reste. Connecter un terminal ajoute une liaison de plus par-dessus : la charge utile est authentifiée contre un secret d’appairage qui a voyagé dans le QR code, pas à travers le serveur, de sorte qu’un relay qui échangerait la charge utile ne pourrait pas produire un tag correspondant.

Tout ce qui précède décrit le réglage par défaut, et ce défaut n’est pas une suggestion que le client pourrait faire changer d’avis au serveur. Un relay neuf est réglé pour exiger un stockage chiffré de bout en bout : une écriture en clair est refusée avec une erreur de politique plutôt qu’acceptée en silence. Les clients lisent la politique depuis l’endpoint de features du serveur avant de créer une session, donc le mode d’une session est convenu avant son premier message.

Un opérateur de serveur dispose de deux autres réglages. L’un peut laisser un compte choisir, si bien que des sessions chiffrées et en clair coexistent sur le même relay — il faut à la fois la politique optionnelle et l’autorisation de désactivation, et cette autorisation est désactivée tant que l’opérateur ne l’active pas. L’autre exige le texte clair, pour les organisations qui gèrent le chiffrement au niveau infrastructure et ont besoin que le serveur puisse lire et traiter le contenu des sessions. Ce dernier est un vrai compromis et il vaut la peine de le dire sans l’adoucir : sur une session en clair, le serveur peut lire la transcription. C’est tout l’objet du réglage.

Le mode est fixé par session à la création, donc une session n’est jamais à moitié dans chacun, et changer le mode d’un compte change ce qui arrive aux nouvelles sessions plutôt que de revenir sur les anciennes. Rien n’est déchiffré rétroactivement, et rien n’est chiffré rétroactivement non plus.

Les variables qui règlent ces trois points, les options de chiffrement au repos en dessous et les contrôles d’identité autour constituent la moitié opérateur du sujet, et vivent sur la page d’auto-hébergement pour les équipes.

La notification push est la seule chose qui sort du modèle, parce qu’elle doit arriver sur un téléphone où rien n’est ouvert. La réponse de Happier, c’est que c’est ton propre ordinateur qui les envoie. Le serveur stocke tes tokens push ; le CLI sur ton propre ordinateur les relit et envoie lui-même la notification, ce qui garde le relay hors d’un chemin où il faudrait sinon lui dire le contenu.

Ce que porte la charge utile est volontairement maigre : le type d’outil ou de requête, et un court indice quand il aide — un fichier comme src/file.ts, un nom de commande, un décompte du type « 3 questions ». L’entrée brute des outils n’y est pas mise. De quoi décider s’il faut attraper le téléphone, sur un écran que n’importe qui derrière toi peut lire.

Tout cela tient sur un relay que tu ne fais pas tourner. La raison d’en faire tourner un à toi, c’est la ligne ci-dessus sur les identifiants et la forme : le chiffrement ne cache pas qui parle à qui, ni à quelle fréquence, et sur ton propre relay ce registre est à toi aussi. Une commande place le relay sur du matériel qui t’appartient, et le chemin devient ton appareil, ton relay, ton ordinateur, sans rien dedans que tu n’aies déployé.

Il n’y a aucune certification sur cette page parce qu’il n’y en a aucune à rapporter, et une page de sécurité qui fait signe vers une conformité qu’elle n’a pas est pire qu’une page qui n’en parle pas. Ce qu’il y a à la place, c’est le code à partir duquel chaque phrase ci-dessus a été écrite, sous licence MIT et lisible avant que tu ne l’exécutes : les primitives dans packages/protocol/src/crypto, le chiffrement de session dans apps/cli/src/api/encryption.ts, la politique de stockage que le serveur applique dans son endpoint de features, et le schéma qui montre exactement quelles colonnes sont en clair.

C’est aussi la réponse honnête à la façon dont tu devrais traiter cette page : comme une carte indiquant où regarder, pas comme une promesse à prendre sur parole. Lis les quatre fichiers, ou fais tourner le relay toi-même et lis ce qu’il annonce à ses clients.

La référence du modèle de chiffrement couvre le même terrain sous forme de procédure — ce qu’une restauration te demande, ce que chaque mode de stockage implique pour un compte, et vers quel flux se tourner quand un appareil ne peut pas encore lire une session.