Comment recevoir un record scellé

Pour recevoir un record scellé, vous partagez une adresse de réception et vous laissez votre logiciel retrouver les records que vos clés peuvent ouvrir. Aucune boîte aux lettres n'est remplie pour vous par le serveur. Votre client parcourt le flux public Label 309, essaie vos clés de réception sur chaque record scellé et affiche ceux qu'il parvient à déchiffrer.

Cette inversion résume toute l'idée : votre boîte de réception est découverte par déchiffrement, et non attribuée par un serveur. La chaîne ne porte jamais de champ destinataire lisible, et le gateway n'a jamais besoin de savoir quels records sont les vôtres.

Qu'est-ce qu'un record scellé ?

Un record scellé est une preuve d'existence dont le contenu est chiffré.

Le record public s'engage toujours sur l'empreinte du texte en clair, si bien que la preuve peut montrer plus tard que ce contenu exact existait avant un temps de bloc public. Le fichier lui-même est chiffré, et le texte chiffré réside dans un emplacement adressé par le contenu, tel qu'Arweave ou IPFS — jamais sur la chaîne. (Pour les mécanismes de la preuve publique, voyez comment fonctionne Label 309.)

Quiconque détient une clé correspondante peut déchiffrer le texte chiffré, récupérer les octets d'origine, recalculer l'empreinte du texte en clair et confirmer que le fichier déchiffré correspond à l'engagement sur la chaîne. Quiconque ne possède pas de clé constate qu'un record scellé existe — mais ne devrait pas pouvoir en lire le contenu.

Que dois-je donner à l'expéditeur ?

Vous donnez à l'expéditeur une adresse de réception. Rien de plus.

Pour les records scellés Label 309, les adresses de réception se présentent sous deux formes :

• age1… — la voie de réception classique X25519.
• age1pqc1… — une voie de réception hybride post-quantique (X25519 combiné à ML-KEM-768, dans la construction X-Wing).

Une adresse de réception est publique et peut être partagée sans risque. Elle permet à quelqu'un de chiffrer un record à votre intention, et rien d'autre. Elle dérive de votre identité, mais ne la révèle pas.

Ne donnez pas votre graine d'identité à l'expéditeur. La graine est la racine privée de votre identité — les 32 octets dont dérivent de manière déterministe votre clé de signature et vos clés de réception. Quiconque la détient peut signer et déchiffrer en votre nom. (Pour comprendre pourquoi la graine est la véritable sauvegarde : votre identité est une graine.)

Comment l'expéditeur crée-t-il le record ?

Le logiciel de l'expéditeur réalise le scellement localement. Dans les grandes lignes :

1. L'expéditeur choisit un fichier ou un message.
2. Le logiciel calcule l'empreinte du texte en clair.
3. Le logiciel génère une clé de contenu à usage unique et chiffre le contenu.
4. Pour chaque destinataire, il enveloppe cette clé de contenu pour la clé de réception du destinataire, produisant un emplacement par destinataire.
5. Le texte chiffré est téléversé vers un stockage adressé par le contenu (tel que ar://).
6. Un record Label 309 est publié sur Cardano, portant l'empreinte du texte en clair et l'enveloppe scellée.

Le record sur la chaîne prouve l'horodatage et porte les emplacements de clé enveloppés. Le texte chiffré stocké contient le fichier chiffré. Votre clé privée est ce qui ouvre votre emplacement. La même séquence — hacher, signer, sceller, partager — est détaillée dans hacher, signer, sceller, partager.

Comment mon client trouve-t-il un record qui m'est destiné ?

Votre client parcourt les records publics et tente de les ouvrir.

C'est la partie qui déconcerte si vous attendez une boîte aux lettres classique. Dans une boîte de réception hébergée, le serveur sait à quel compte appartient un message et le route en conséquence. Un record scellé Label 309 ne porte aucun routage de ce genre. L'enveloppe énumère des emplacements de clé enveloppés, mais aucune clé publique de destinataire n'apparaît nulle part dans les données transmises — il n'y a aucun champ destinataire à lire.

Votre client synchronise donc le flux public des records Label 309 et, pour chaque record scellé, vérifie si l'un des emplacements s'ouvre avec les clés de réception de votre identité. C'est le déchiffrement à l'essai local : une tentative de désenvelopper chaque emplacement, effectuée entièrement sur votre appareil. Si un emplacement s'ouvre, le record est le vôtre et votre client l'ajoute à votre boîte de réception. Si aucun ne s'ouvre, votre client l'ignore.

Une conséquence subtile mais importante : l'ordre des emplacements ne révèle rien non plus. Un expéditeur mélange les emplacements avant de publier, de sorte que même la position du « destinataire principal » ne porte aucun signal.

Le déchiffrement à l'essai doit-il télécharger chaque fichier ?

Non. Le déchiffrement à l'essai s'exécute sur l'enveloppe portée par le record sur la chaîne, et non sur le fichier stocké.

Les emplacements enveloppés et une petite balise d'authentification se trouvent dans les métadonnées du record elles-mêmes. Votre client peut déterminer qu'un record vous est adressé — et récupérer la clé de contenu — à partir de ces seuls octets sur la chaîne, avant de récupérer le moindre texte chiffré. C'est important, car le texte chiffré peut être volumineux : un client de bureau peut d'abord découvrir quels records sont les vôtres, puis récupérer les fichiers chiffrés à la demande lorsque vous les ouvrez, ou les pré-mettre en cache selon vos réglages.

Pour un client privilégiant le mode hors ligne, cette séparation est le fondement :

• synchroniser le flux public des records ;
• déchiffrer localement à l'essai sur les enveloppes ;
• mettre en cache le texte chiffré correspondant si vous le souhaitez ;
• déchiffrer à la demande lorsque vous ouvrez un fichier ;
• garder utilisable, sans réseau, tout ce qui est déjà synchronisé.

Que sait réellement le gateway ?

Un gateway sait ce que sait n'importe quel observateur public, plus les détails opérationnels du service qu'il exploite.

Pour un gateway hébergé, cela peut inclure l'activité du compte, l'usage de l'API, votre parcours de devis et de publication, l'activité de téléversement, l'état du solde, des données d'infrastructure au niveau réseau, ainsi que les métadonnées publiques des records que tout le monde peut voir. (Pour le tableau complet de cette frontière, voyez ce que CardanoWall peut voir.)

Ce dont il n'a pas besoin, c'est de votre graine d'identité, de vos clés privées de réception, ni d'aucune capacité à déchiffrer le contenu scellé à votre place. La propriété de confidentialité ici n'est pas « le serveur n'apprend rien sur rien » — ce serait malhonnête. Elle est plus étroite et plus utile : l'identification du destinataire et le déchiffrement se font localement, si bien qu'aucun champ destinataire lisible n'est publié et qu'aucune clé privée n'est jamais envoyée au gateway. Le gateway est aveugle au destinataire par conception ; toute tentative de filtrer les records par destinataire est tout simplement ignorée, car il n'existe aucune colonne destinataire sur laquelle filtrer.

Pourquoi n'y a-t-il aucun champ destinataire public ?

Parce qu'un champ destinataire public divulguerait le graphe social.

Si chaque record scellé indiquait exactement à qui il était destiné, un observateur pourrait cartographier les relations entre expéditeurs et destinataires sans lire un seul octet de texte en clair. Pour des processus confidentiels — une source qui contacte une rédaction, une offre scellée, des pièces sous séquestre — cette exposition peut constituer l'essentiel du risque.

Label 309 recourt à des emplacements de clé enveloppés à la place. Le record contient des données chiffrées que seuls les détenteurs de clés prévus peuvent ouvrir. Un observateur peut voir qu'un record est scellé et combien d'emplacements il contient, mais pas une liste lisible des destinataires.

Ce n'est pas un anonymat parfait, et il ne faut pas le présenter comme tel. Le nombre d'emplacements, l'horodatage de publication et des métadonnées externes peuvent encore révéler quelque chose, et un expéditeur qui doit déjouer la corrélation temporelle doit publier en dehors du calendrier sensible. Ce que la conception élimine, c'est la fuite la plus évidente : une colonne destinataire publique sur un registre permanent.

Et si j'ai plusieurs identités ?

Votre client essaie chaque identité déverrouillée.

Vous pouvez garder une identité pour vos records personnels, une pour une entreprise, une pour la réception des dossiers juridiques et une pour un canal confidentiel à haut risque. Chacune possède sa propre graine et ses propres clés de réception, de sorte qu'un record scellé pour l'une reste invisible aux autres tant que les clés de cette identité ne sont pas essayées.

Un client privilégiant le mode hors ligne suit indépendamment la progression de chaque identité dans le flux des records. C'est cette indépendance qui vous permet d'importer plus tard une ancienne graine et de faire reparcourir au client l'intégralité du flux pour cette identité — plutôt que de démarrer à aujourd'hui et de manquer silencieusement tout ce qui a été envoyé avant l'import.

Que se passe-t-il lorsque je restaure une ancienne graine d'identité ?

Un logiciel compatible redérive les mêmes clés de réception à partir de la graine, de manière déterministe.

Cela signifie qu'une ancienne graine peut retrouver d'anciens records scellés, dès lors que les records sont encore sur la chaîne pour être parcourus et que le texte chiffré reste récupérable ou mis en cache. Le client reparcourt le flux public, déchiffre à l'essai les enveloppes scellées et reconstruit la vue de la boîte de réception pour cette identité. Restaurer la graine restaure la capacité à reconnaître les records qui lui sont destinés — le gateway ne détient aucune boîte aux lettres privée à vous rendre.

C'est l'une des raisons les plus claires de l'importance de la graine, et la raison pour laquelle la graine d'identité mérite toujours votre attention. Si vous perdez la graine d'une identité destinataire, les records scellés qui lui sont adressés peuvent devenir illisibles — alors même que les preuves publiques restent sur la chaîne et continuent de se vérifier. Le chiffrement n'a, par conception, aucune porte dérobée de récupération ; la graine est le chemin de récupération.

Un client de bureau peut-il recevoir des records hors ligne ?

Il peut fonctionner avec tout ce qu'il a déjà synchronisé.

CardanoWall Desktop — une application Rust open source, construite avec Tauri sur le SDK Rust open source (github.com/cardanowall) — est conçue exactement autour de ce principe. Une fois qu'elle a synchronisé des records et mis en cache du texte chiffré, elle liste, recherche, vérifie et déchiffre ces données locales sans aucune connexion réseau. Si un record n'a pas encore été synchronisé, ou qu'un texte chiffré n'a pas été récupéré, elle a besoin du réseau pour les obtenir — et le dit clairement, plutôt que d'échouer en silence.

Cela reflète le comportement d'un client de messagerie sérieux : hors ligne ne veut pas dire que le monde s'arrête. Votre miroir local, votre cache et votre coffre deviennent la source de vérité jusqu'au retour du réseau. (Pour en savoir plus sur le modèle hors ligne : preuves hors ligne et CardanoWall Desktop.)

Comment vérifier qui a envoyé un record ?

Recevoir un record scellé prouve seulement que votre clé peut l'ouvrir. Cela ne prouve pas qui l'a envoyé.

Dans Label 309, la paternité est facultative. Si un record porte une signature, cette signature montre qu'une clé particulière s'est portée garante du record — mais il vous faut encore du contexte pour décider à qui appartient cette clé. Si un record n'est pas signé, l'expéditeur a peut-être délibérément évité de lier une quelconque identité, ce qui est précisément ce qu'exigent certains processus confidentiels.

Pour les contenus sensibles, confirmez les clés des expéditeurs et les adresses de réception hors bande : tenez un carnet d'adresses, comparez les empreintes de clés et utilisez un annuaire ou une confirmation directe à laquelle vous accordez déjà votre confiance. Le chiffrement protège le contenu ; décider à qui appartient la clé avec laquelle vous échangez est une décision de confiance distincte, et humaine. Les mécanismes du carnet d'adresses sont détaillés dans comment fonctionne le carnet d'adresses.

Qu'est-ce qui peut mal tourner ?

L'échec le plus lourd de conséquences est la perte de la graine. Perdez la graine d'identité d'une identité destinataire et vous risquez de perdre la capacité à déchiffrer les records qui lui sont adressés — définitivement, pour cette identité.

Les autres sont d'ordre opérationnel, et un bon logiciel devrait les exposer honnêtement plutôt que les masquer :

• le texte chiffré n'a jamais été téléversé avec succès ;
• l'emplacement de stockage est temporairement indisponible ;
• l'expéditeur a utilisé la mauvaise adresse de réception ;
• vous avez importé la mauvaise identité ;
• l'appareil local est compromis (un programme malveillant sur une machine déverrouillée peut lire des secrets en mémoire — voyez le mode ordinateur public) ;
• le record est trop récent et n'a pas atteint la profondeur de confirmation que vous exigez ;
• le record est valide mais non signé, de sorte qu'aucune identité d'expéditeur n'est établie.

Un système de preuve gagne la confiance en montrant l'incertitude, non en la dissimulant.

En résumé

Pour recevoir des records scellés :

1. Partagez une adresse de réception.
2. Gardez votre graine d'identité en sécurité et sauvegardée.
3. Laissez votre client parcourir le flux public Label 309.
4. Laissez-le déchiffrer localement à l'essai.
5. Ouvrez et vérifiez les records que vos clés peuvent déchiffrer.

Votre boîte de réception n'est pas une liste, côté serveur, de messages adressés à votre compte. C'est une vue locale des records scellés que votre identité peut ouvrir — et c'est précisément ce qui tient le gateway à l'écart de votre correspondance privée.

Une dernière note honnête sur les limites : un record scellé garde le texte en clair chiffré pour ses détenteurs de clés, mais il ne garantit pas l'anonymat, et quiconque le déchiffre peut ensuite choisir de divulguer le texte en clair. La preuve montre que des octets précis existaient avant un temps public. Elle ne prouve ni vérité, ni propriété, ni paternité — voyez ce qu'une preuve ne prouve pas.

Pour aller plus loin

• Qu'est-ce qu'une adresse de réception ?
• Vérifiez un destinataire avant de sceller un fichier
• Divulgation confidentielle sans fichiers publics
• Le standard ouvert et son code de référence : label309.org et github.com/cardanowall. Label 309 est soumis au processus CIP de Cardano et en cours d'examen.