Hacher, signer, sceller, partager : les quatre niveaux d'une preuve CardanoWall

Une preuve CardanoWall comporte quatre niveaux concrets, et c'est à vous de décider jusqu'où vous montez l'échelle :

• Hacher prouve que des octets exacts existaient avant un instant public.
• Signer ajoute une affirmation adossée à une clé : une identité précise s'est portée garante du record.
• Sceller chiffre le fichier d'origine pour le conserver à titre privé aux côtés de la preuve.
• Partager prépare ce fichier scellé pour des destinataires précis, qui pourront plus tard le découvrir et le déchiffrer avec leurs propres clés.

Chaque niveau s'appuie sur le précédent, et le standard commun qui les sous-tend tous est Label 309. C'est la façon la plus simple de comprendre ce qu'est CardanoWall : non pas un simple endroit où déposer des empreintes sur une blockchain, mais une manière en couches de rendre les records durables, privés et vérifiables — en partant d'un simple horodatage et en n'ajoutant que la protection réellement nécessaire à une situation.

Niveau 1 : hacher — prouver que des octets exacts existaient avant un instant

Le premier niveau est la preuve d'existence classique.

Vous prenez un fichier, un message, un jeu de données, un fichier média, un artefact de build, un rapport ou un manifeste. CardanoWall calcule une empreinte cryptographique des octets exacts et publie cette empreinte dans un record Label 309 sur Cardano.

Plus tard, quiconque dispose des mêmes octets d'origine peut recalculer l'empreinte. Si elle correspond à celle du record, le vérificateur sait que ces octets exacts existaient au plus tard à l'instant du bloc de la transaction. Le contrôle s'effectue sur la chaîne publique Cardano — il ne nécessite aucun compte CardanoWall et ne fait confiance à aucun serveur CardanoWall.

L'intérêt : le fichier lui-même n'a jamais besoin d'être public. Un contrat privé, un instantané de jeu de données, un manifeste de version logicielle ou un dossier de pièces juridiques peuvent chacun porter une preuve publique. Le record dit que ces octets existaient. Il n'a pas à montrer les octets.

À quoi servent les preuves par empreinte ?

Les preuves par empreinte sont solides lorsque la question porte sur la chronologie et l'intégrité. Elles répondent à des interrogations comme :

• Ce fichier exact existait-il avant une échéance ?
• Est-ce le même PDF que celui horodaté le mois dernier ?
• Ce manifeste de version était-il déjà engagé avant l'incident ?
• Cet instantané de jeu de données existait-il avant que le modèle ne soit entraîné dessus ?
• Ce fichier média existait-il avant d'être modifié ou contesté ?

Elles sont aussi efficaces. Un fichier de plusieurs gigaoctets se réduit à un court condensé, et un fichier privé devient un engagement public sans divulguer son contenu.

La limite compte tout autant : une empreinte ne prouve pas qui a créé le fichier, ni que le fichier est véridique, ni que quelqu'un en est propriétaire. Elle prouve que les octets exacts existaient avant un instant public — rien de plus. Cela suffit pour de nombreux flux de travail. Pour les autres, CardanoWall ajoute les couches suivantes.

Niveau 2 : signer — rattacher une clé d'identité au record

Le deuxième niveau ajoute une signature.

Une signature permet à une clé de se porter garante du record. Au lieu de prouver seulement que des octets existaient, le record peut aussi montrer qu'une clé d'identité précise a signé la preuve. Dans Label 309, il s'agit d'une signature COSE_Sign1 détachée et facultative sur le corps du record, et la paternité n'est jamais exigée — un record sans signature reste une preuve complète et entièrement vérifiable.

Cette option change le sens concret. Pour un créateur individuel, un record signé peut rattacher un travail à l'identité CardanoWall de son auteur. Pour une entreprise, il peut montrer qu'une clé approuvée s'est portée garante d'un rapport, d'un manifeste de version, d'un instantané de conformité ou d'un engagement sur un jeu de données. Pour un flux de travail automatisé, il distingue « quelqu'un a horodaté ce fichier » de « notre système a signé ce record dans le cadre du processus ».

La signature ne remplace pas l'empreinte ; elle se superpose à elle.

• L'empreinte dit : ces octets exacts existaient.
• La signature dit : cette clé a signé le record qui formule cette affirmation.

Que ne prouve pas une signature ?

Les signatures sont puissantes, mais elles ne sont pas magiques.

Une signature prouve le contrôle d'une clé au moment de la signature. À elle seule, elle ne prouve pas l'identité réelle de la personne ou de l'entreprise derrière cette clé. Cette identité vient du contexte : la manière dont la clé a été créée, celle dont elle a été publiée, celle dont une organisation la gère et celle dont les autres en viennent à lui faire confiance.

Une signature ne prouve pas non plus que le signataire a payé les frais de la transaction ni qu'il l'a soumise à Cardano. Dans Label 309, la signature couvre le corps du record, pas l'ensemble de la transaction Cardano. C'est délibéré, et c'est ce qui maintient les records portables : un gateway, un système d'automatisation ou tout tiers peut publier un record signé sans devenir l'auteur du contenu. Une signature vérifiée se lit « signé par cette clé » — jamais « cette clé a soumis la transaction ».

En clair : signez lorsque vous voulez que la preuve dise non seulement « ceci existait », mais aussi « cette identité s'est portée garante de la preuve ».

Niveau 3 : sceller — conserver une copie chiffrée avec la preuve

Le troisième niveau ajoute une conservation chiffrée.

Une preuve par simple empreinte a une faiblesse pratique : le vérificateur a tout de même besoin des octets d'origine. Perdez le fichier, ou modifiez-le ne serait-ce que d'un octet, et vous ne pouvez plus produire le contenu qui correspond au record.

Le scellement résout ce problème en chiffrant le fichier et en conservant le contenu chiffré avec la preuve, dans un emplacement adressé par le contenu tel qu'Arweave ou IPFS. Le record sur la chaîne s'engage toujours sur l'empreinte du texte en clair — jamais sur le texte chiffré — de sorte que la revendication d'horodatage reste inchangée. Le fichier n'est jamais publié en clair. Quiconque détient la bonne clé peut plus tard récupérer le texte chiffré, le déchiffrer, recalculer l'empreinte du texte en clair et prouver qu'il s'agit bien du fichier à l'origine du record.

Cela change la donne. Avec une preuve par simple empreinte, vous conservez vous-même le fichier d'origine. Avec une preuve scellée, vous pouvez conserver une copie chiffrée de l'original au sein même du flux de preuve.

Quand le scellement en vaut-il la peine ?

Le scellement compte lorsque le fichier d'origine est suffisamment important pour que sa perte affaiblisse la preuve. Pensez à :

• les dossiers de pièces juridiques et les contrats signés ;
• les rapports de conformité et les journaux d'incident sensibles ;
• les fichiers créatifs originaux et les données de recherche ;
• les manifestes de jeux de données, les prompts et sorties d'IA, et les artefacts de version.

Dans chaque cas, une empreinte est utile, mais ce sont les octets d'origine que vous pourriez devoir produire plus tard. La preuve d'existence scellée vous permet de garder ces octets chiffrés tandis que l'horodatage reste public. La chaîne prouve la chronologie ; le chiffrement protège le contenu.

Niveau 4 : partager — remettre un fichier scellé à des destinataires précis

Le quatrième niveau ajoute une remise privée aux destinataires.

Parfois, la preuve n'est pas seulement pour vous. Vous pouvez avoir besoin d'envoyer des pièces chiffrées à un avocat, un auditeur, un partenaire, un journaliste, un client, un régulateur ou une équipe interne.

Si vous connaissez l'adresse de réception du destinataire, CardanoWall peut créer un record scellé que le destinataire pourra ouvrir plus tard avec sa propre clé. Ce record possède toujours un horodatage public et s'engage toujours sur l'empreinte du texte en clair. Il peut toujours conserver un fichier chiffré. Mais désormais, le contenu chiffré peut être ouvert par des destinataires précis, pas seulement par l'expéditeur. C'est là que CardanoWall commence à ressembler moins à un outil d'horodatage qu'à un système de remise de records sécurisé.

Comment fonctionne la remise privée sans carnet d'adresses public ?

La remise aux destinataires ne nécessite aucun carnet d'adresses public sur la chaîne, et la clé publique d'aucun destinataire n'est jamais inscrite dans le record sous forme de champ lisible.

Voici le déroulement. Un destinataire possède une adresse de réception. L'expéditeur l'obtient hors bande — directement auprès du destinataire, depuis un profil, une page d'entreprise ou un autre canal de confiance. Lorsque l'expéditeur construit un record scellé, l'enveloppe contient des emplacements de clé chiffrés par destinataire que seuls les destinataires prévus peuvent ouvrir.

Côté réception, le logiciel du destinataire parcourt les records scellés publics et déchiffre à l'essai — il essaie localement chaque emplacement avec ses propres clés. Lorsqu'un emplacement s'ouvre, le record apparaît dans la boîte de réception de ce destinataire. Le serveur ne déchiffre jamais le message et n'a pas besoin de savoir qui est le destinataire. (Voir comment recevoir des records scellés pour le détail du côté destinataire.)

Ce n'est pas une promesse d'anonymat parfait. Les délais, les flux de paiement, les métadonnées réseau, le comportement du navigateur et les erreurs opérationnelles peuvent encore laisser fuir des informations, et un destinataire peut toujours partager le texte en clair une fois qu'il l'a déchiffré. Ce que la conception apporte est plus étroit et bien réel : le record Label 309 lui-même ne publie ni le texte en clair ni une liste de destinataires lisible — un observateur voit seulement qu'un record est scellé et combien d'emplacements de clé il contient, jamais à qui il s'adresse.

Pourquoi le chiffrement post-quantique a-t-il sa place dans l'histoire du partage ?

Les records scellés peuvent vivre très longtemps. Si du contenu chiffré est stocké de façon permanente ou semi-permanente, un attaquant n'a pas besoin de le casser aujourd'hui : il peut stocker le texte chiffré dès maintenant et réessayer plus tard, avec un meilleur matériel et une meilleure cryptanalyse. C'est le problème du « harvest now, decrypt later » (moissonner maintenant, déchiffrer plus tard).

C'est pourquoi Label 309 prend l'agilité algorithmique au sérieux. Les adresses de réception existent sous deux formes — une adresse X25519 classique et une adresse hybride post-quantique facultative qui combine X25519 et ML-KEM-768 (une construction de type X-Wing). L'hybride conserve la sécurité classique de X25519 comme socle tout en ajoutant une résistance face à un futur attaquant quantique ; c'est donc le meilleur choix par défaut pour un contenu destiné à survivre aux hypothèses cryptographiques d'aujourd'hui. L'objectif n'est pas de revendiquer une sécurité permanente — rien d'honnête ne le peut — mais d'éviter de concevoir un système de preuve qui suppose que le confort cryptographique actuel tiendra éternellement.

La version visible par l'utilisateur reste simple : protégez votre graine d'identité, préférez l'adresse de réception hybride post-quantique lorsque votre destinataire en publie une, et laissez le logiciel gérer la cryptographie.

Comment les quatre niveaux fonctionnent-ils ensemble ?

Les niveaux ne sont pas des produits distincts. Ce sont des couches sur un seul standard :

• Publiez une simple preuve par empreinte lorsque vous n'avez besoin que d'un horodatage.
• Ajoutez une signature lorsque vous voulez qu'une clé d'identité se porte garante du record.
• Scellez le fichier lorsqu'il importe de conserver les octets d'origine exacts.
• Partagez le fichier scellé lorsque des destinataires précis ont besoin d'un accès privé.

Comme le même standard sous-jacent prend en charge chaque choix, vous pouvez commencer simplement et n'opter pour des couches plus fortes que lorsque la situation l'exige.

Quel niveau devriez-vous utiliser ?

• Hacher lorsque le fichier d'origine est facile à conserver et que la seule question est de savoir si ces octets existaient avant un certain instant.
• Signer lorsque vous voulez qu'une identité adossée à une clé se porte garante de la preuve.
• Sceller lorsque les octets d'origine sont assez sensibles ou importants pour justifier la conservation d'une copie chiffrée avec la preuve.
• Partager lorsqu'un tiers a besoin de recevoir le contenu chiffré et de le vérifier ultérieurement.

Il existe aussi un cinquième outil, transversal aux quatre : le regroupement Merkle, pour les cas où vous avez trop d'empreintes pour une publication une par une — artefacts CI/CD, journaux quotidiens, instantanés de jeux de données, médias générés, ou tout flux où des milliers d'éléments doivent être engagés sous un seul record et une seule racine.

Que ne prouvent toujours pas ces preuves ?

Même avec les quatre niveaux, la preuve d'existence reste précise quant à ses affirmations.

Elle peut prouver que des octets exacts existaient, qu'une clé a signé le record, que du contenu chiffré a été conservé, que le contenu a été remis à des clés précises et — avec une racine de Merkle — qu'un élément appartenait à un lot engagé.

Elle ne prouve pas, à elle seule, que le contenu est véridique, que quelqu'un en détient la propriété légale, qu'un jeu de données a été collecté licitement, ou qu'un processus défaillant est sain. Pour en savoir plus sur ces limites, voir ce qu'une preuve ne prouve pas. CardanoWall vous fournit une couche de preuve durable ; le processus métier autour de cette preuve compte toujours.

La version courte

• Hacher est l'horodatage.
• Signer est l'affirmation d'identité.
• Sceller est la conservation chiffrée.
• Partager est la remise privée.

Ensemble, ces niveaux transforment la preuve d'existence d'une simple empreinte sur une chaîne en un flux de travail exploitable pour les fichiers, les jeux de données, les pièces, les versions logicielles, les sorties d'IA et les records confidentiels — et parce que Label 309 est un standard ouvert doté d'un outillage open source, les mêmes quatre niveaux fonctionnent via le site web, la CLI ou l'implémentation de n'importe qui d'autre.

Pour aller plus loin

• Qu'est-ce qu'une preuve d'existence ? — le niveau « empreinte », en détail.
• Comment recevoir des records scellés — le côté destinataire du « partage ».
• Un seul record pour des milliers de fichiers — le regroupement Merkle sur les quatre niveaux.
• Ce qu'une preuve ne prouve pas — les limites à garder en tête.
• Label 309 — le standard ouvert, proposé au processus CIP de Cardano et en cours d'examen par les éditeurs CIP (PR #1205).
• github.com/cardanowall — les SDK open source et la CLI cardanowall.