Modèle de sécurité

La sécurité de Label 309 repose sur une seule idée : une preuve est quelque chose que la partie qui s’y fie vérifie par elle-même. Un vérificateur fait confiance à la chaîne publique Cardano et — pour les affirmations sur le contenu — aux octets qu’on lui remet. Il ne fait confiance à rien d’autre : ni au publicateur, ni à un domaine, ni à un serveur, ni à l’opérateur de la passerelle par laquelle il a justement lu la transaction. Chaque garantie de cette page soit découle de cette posture, soit en marque la frontière, soit nomme un risque résiduel qui se situe en dehors.

Cette page est le modèle de menaces du standard lui-même : le modèle de confiance sous lequel opère un vérificateur conforme, les propriétés de confidentialité d’une PoE scellée non signée, les obligations cryptographiques que toute implémentation DOIT respecter et les limites que le format de sérialisation ne dépasse pas — et ne saurait dépasser. Elle ne décrit pas la sécurité opérationnelle d’un déploiement particulier ; elle décrit ce que le format garantit à quiconque l’implémente correctement.

Le modèle de confiance

Une partie qui vérifie une preuve Label 309 pose une question circonscrite : ces octets existaient-ils à l’heure de ce bloc ou avant, et ce verdict dépend-il du bon comportement de quiconque autre que Cardano ? Le standard est conçu de sorte que la réponse à la seconde moitié soit toujours « non ». Il n’y a aucun intermédiaire contrôlé par l’émetteur à aucune étape : la passerelle de chaîne et la passerelle de stockage qu’un vérificateur consulte sont des sources de données non fiables, vérifiées cryptographiquement lorsque c’est possible et recoupées quant à l’inclusion et à la finalité.

Ce à quoi un vérificateur fait confiance :

• La chaîne publique Cardano. La transaction, ses métadonnées sous le label 309 et l’heure de son bloc sont des faits répliqués sur chaque nœud Cardano. Un vérificateur les lit à travers une passerelle de son choix et peut en recouper plusieurs.
• Les octets du contenu, lors de la vérification d’une affirmation sur le contenu. Un condensé présent dans l’enregistrement s’engage sur une séquence d’octets précise. Un vérificateur qui détient ces octets recalcule l’empreinte et la compare ; il ne croit personne sur parole quant à la correspondance des octets.

Ce à quoi un vérificateur ne fait pas confiance :

• Le publicateur. Label 309 n’a pas de champ issuer. N’importe quel portefeuille peut publier n’importe quel enregistrement ; la validité de l’enregistrement est indépendante de qui l’a soumis. Un vérificateur ne se demande jamais « ce publicateur est-il digne de confiance ? » — la question n’a pas sa place dans le modèle. Voir l’invariant d’indépendance vis-à-vis de l’émetteur sur l’Introduction.
• Un serveur ou un domaine. Aucune étape de la vérification ne contacte un service exploité par le publicateur. Il n’y a aucun registre canonique à consulter, aucun point de terminaison de statut à interroger, aucune autorité d’identité contre laquelle résoudre une clé.
• L’opérateur d’une passerelle. Les passerelles Cardano, Arweave et IPFS à travers lesquelles un vérificateur lit sont interchangeables et contrôlées sur le contenu (ci-dessous). Une passerelle est un moyen de transport, non une racine de confiance.

Pourquoi les passerelles ne sont pas une racine de confiance

Un vérificateur peut lire la même transaction à travers n’importe quelle passerelle Cardano, et lire le même contenu à travers n’importe quelle passerelle Arweave ou IPFS. Aucune d’elles n’est tenue pour digne de confiance quant à la restitution de données honnêtes, car ce qu’elles renvoient est vérifiable de façon indépendante :

• Une passerelle ne peut pas falsifier un enregistrement qui porte une signature valide — elle ne détient pas la clé privée du signataire, et le vérificateur recalcule les octets signés et les vérifie lui-même. Voir Signatures.
• Une passerelle ne peut pas substituer le contenu sous une URI adressée par le contenu sans détection : un CID ipfs:// est un multihash que le vérificateur recalcule à partir des octets récupérés, et un identifiant de transaction ar:// s’engage sur les données sous le consensus Arweave. Sur un élément conforme, la table hashes sur la chaîne est un second lien, indépendant, vers le texte en clair, recalculé au moment de la récupération.
• Une passerelle qui retient une transaction ou rapporte de façon erronée à quelle profondeur elle est enfouie relève d’un déni de service, non d’une falsification. Un vérificateur qui lit à travers plus d’une passerelle et s’interrompt en cas de désaccord transforme « une passerelle malhonnête » en « une collusion de toutes les passerelles qu’il a choisies » — ce qu’il contrôle.

La profondeur de bloc — combien de confirmations un vérificateur exige avant de considérer un enregistrement comme acquis — relève de la politique du vérificateur, et non d’une valeur imposée par Label 309. Le standard ne fixe aucune profondeur numérique ; la partie qui s’y fie établit un seuil adapté à sa propre tolérance au risque. Voir Vérification.

Propriétés de confidentialité de la PoE scellée

Une PoE scellée maintient un texte en clair confidentiel tout en ancrant son horodatage. Au-delà de la confidentialité, la construction est conçue pour que la chaîne divulgue le moins possible sur le message et rien sur son audience. Ce sont des garanties du format de sérialisation : elles valent pour toute implémentation correcte, car ce sont des propriétés des octets, et non d’un déploiement particulier.

Anonymat de l’expéditeur pour la PoE scellée non signée

Une PoE scellée non signée — un enregistrement portant enc et aucun sigs — NE DOIT PAS divulguer l’identité de l’expéditeur sur la chaîne. Ses octets sur le wire DOIVENT être indépendants des clés à long terme de l’expéditeur.

Cela tient structurellement :

• Aucune clé de signataire sur le wire. La clé d’identité d’un expéditeur n’atteint la chaîne qu’à travers une entrée sigs. Un enregistrement sans sigs ne porte aucun octet du côté signataire. La paternité est facultative ; l’anonymat est le comportement par défaut. Les clés à long terme X25519 et Ed25519 de l’expéditeur n’apparaissent jamais dans un enregistrement non signé.
• Encapsulation fraîche par slot. Chaque slot de destinataire porte du matériel KEM propre à l’enregistrement et au slot, généré à neuf au moment du scellement — la clé publique éphémère X25519 dans slot.epk sur le chemin x25519, ou le texte chiffré X-Wing dans slot.kem_ct sur le chemin mlkem768x25519. Il n’a aucun rapport avec la clé à long terme de l’expéditeur et ne révèle rien qui relie des enregistrements à un auteur commun.
• Slots mélangés. Le tableau de slots est mélangé avec un CSPRNG avant la publication, de sorte que l’ordre positionnel (« le destinataire principal d’abord ») ne véhicule aucun signal.

Un producteur qui signe ultérieurement un enregistrement divulgue sa clé d’identité uniquement dans cet enregistrement ; elle n’apparaît dans aucun enregistrement non signé antérieur, et aucune opération ne ramène le matériel KEM par slot des enregistrements antérieurs vers l’auteur. Les clés d’identité X25519 et Ed25519 se dérivent de la clé maîtresse via des chaînes de contexte HKDF distinctes, et une clé publique Ed25519 ne peut ni dériver ni correspondre à une clé publique X25519, de sorte que signer un enregistrement ne relie jamais entre eux les enregistrements non signés. Opter pour la paternité est un acte tourné vers l’avant, non une désanonymisation rétroactive.

Cet invariant ne couvre que les octets de l’enregistrement label-309. L’adresse Cardano qui acquitte les frais dans les entrées de la transaction, l’identité du producteur au niveau réseau telle que la voit une passerelle et toute métadonnée du blob de texte chiffré hors chaîne sont hors du format de sérialisation — Label 309 vit dans les métadonnées, non dans les entrées de la transaction, et ne peut pas se défendre contre la corrélation par le payeur des frais. Un producteur qui a besoin de l’anonymat du payeur des frais doit y répondre à la couche de construction de la transaction.

Non-corrélation des destinataires

Un enregistrement scellé ne nomme jamais ses destinataires. Un destinataire reconnaît qu’un message est le sien uniquement en déchiffrant à l’essai un slot avec succès ; il n’y a aucun champ d’adressage à lire. Deux garanties distinctes en découlent, et elles ne doivent pas être confondues.

La première vaut pour les deux KEM et pour tout observateur :

• Les destinataires ne peuvent pas se voir entre eux. Chaque slot est une clé enveloppée de façon indépendante. Un destinataire qui ouvre son propre slot n’en déduit rien sur aucun autre slot et ne peut pas savoir à qui d’autre le message était adressé.
• Aucune clé publique de destinataire sur le wire. Seuls l’encapsulation par slot (epk ou kem_ct) et la clé enveloppée apparaissent. Un observateur sans clés candidates ne peut pas énumérer les destinataires — il n’apprend que le nombre de slots, la famille de KEM (enc.kem) et la distinction entre scellé et ouvert.

La seconde — l’anonymat du destinataire face à un adversaire qui détient déjà un ensemble de clés publiques de destinataire candidates et veut tester si un slot est adressé à l’une d’elles — est une propriété plus forte, spécifique au KEM, et le standard ne la revendique que pour le chemin classique :

• x25519 est à confidentialité de clé (key-private). L’epk par slot est une clé publique éphémère fraîche, statistiquement indépendante de la clé du destinataire. À partir du seul epk et du seul wrap, un adversaire détenant les clés ne peut pas décider quel candidat (s’il en est) un slot vise, sans la clé privée correspondante.
• mlkem768x25519 ne la revendique pas. L’anonymat du destinataire face à un adversaire détenant les clés est une propriété distincte non impliquée par la sécurité IND-CCA du KEM hybride, et elle n’est pas revendiquée pour le chemin X-Wing tant qu’elle n’est pas justifiée de façon indépendante pour X-Wing. Un déploiement dont le modèle de menace exige l’anonymat du destinataire face à un adversaire détenant les clés NE DOIT PAS s’appuyer sur le chemin hybride pour cette propriété. Les fuites honnêtes ci-dessus — nombre de slots, famille de KEM, scellé versus ouvert — sont identiques pour les deux KEM ; rien de plus sur les destinataires n’est exposé sur l’un ou l’autre chemin.

Liaison au texte en clair

Le condensé sur la chaîne s’engage sur le texte en clair, non sur le texte chiffré. Un destinataire qui déchiffre une PoE scellée recalcule l’empreinte du texte en clair et la compare à la table hashes sur la chaîne. Cela signifie qu’une couche de stockage qui sert un texte chiffré altéré est démasquée après le déchiffrement, indépendamment du modèle d’intégrité propre à l’URI — l’affirmation d’horodatage est une affirmation sur le texte en clair sur lequel l’expéditeur s’est engagé, et rien de ce que fait la passerelle ne peut la satisfaire avec des octets différents.

Indépendance vis-à-vis de la rediffusion

Les signatures d’un enregistrement sont fixées au moment où sa transaction est soumise. La chaîne n’a aucune notion d’un « ensemble de signataires étendu » s’accumulant au fil des transactions.

Rediffuser un corps d’enregistrement identique dans une transaction distincte avec un ensemble sigs différent crée un enregistrement séparé et indépendant à sa propre heure de bloc — jamais une extension de l’original.

Une partie qui souhaite endosser un enregistrement déjà publié publie son propre enregistrement — référençant le même contenu, ou pointant vers la transaction antérieure via supersedes — signé par sa clé. Elle n’adjoint pas un témoin à l’enregistrement d’autrui. En conséquence, un attaquant qui copie les octets d’un enregistrement signé dans une nouvelle transaction ne devient pas cosignataire de l’original : il produit une affirmation postérieure et dupliquée avec les sigs qu’il a choisis, et l’heure de bloc antérieure de l’original demeure l’enregistrement canonique de l’existence. Les vérificateurs et les indexeurs NE DOIVENT PAS fusionner deux transactions aux corps d’enregistrement identiques en une seule vue à « signataires combinés » ; le faire fausserait la sémantique d’heure de bloc par enregistrement sur laquelle s’appuient les consommateurs en aval.

Règles normatives pour les implémentations

Les règles suivantes sont normatives en matière de sécurité pour toute implémentation conforme, quel que soit le langage ou la plateforme. Les mots-clés de RFC 2119 / RFC 8174 sont employés au sens normatif.

Aucune cryptographie inédite

Label 309 n’admet délibérément que des primitives bien analysées, chacune nommée dans les registres d’algorithmes et implémentée par une bibliothèque auditée. Une implémentation NE DOIT PAS introduire de chiffreur symétrique, de KDF, de construction de signature ni de stanza d’enveloppement de clés qui lui soient propres. Le format de sérialisation est une composition de parties standard précisément pour que sa sécurité se réduise à la sécurité de ces parties.

Chiffrement authentifié uniquement

Tout chiffrement symétrique dans Label 309 — la couche de contenu et l’enveloppement de clé par slot — est AEAD. Il n’y a aucun mode de chiffrement non authentifié nulle part dans le format. Un déchiffreur dont la vérification du tag AEAD échoue DOIT faire remonter une erreur structurée avec un discriminateur de code stable et NE DOIT PAS poursuivre jusqu’à renvoyer des octets non authentifiés. Les données authentifiées supplémentaires font partie du calcul du tag, de sorte qu’un AAD erroné échoue de façon identique à une clé erronée — il n’y a aucun état de succès partiel à sonder.

Comparaison de secrets à temps constant

Une boucle de comparaison dont le temps d’exécution dépend d’octets secrets est un oracle. Toute vérification d’égalité sur un secret ou sur un tag MAC/AEAD DOIT s’effectuer à temps constant :

• Le MAC de l’ensemble de slots et tout tag HMAC — une fuite temporelle octet par octet sur un MAC de 32 octets peut, sous répétition adverse, récupérer le tag.
• La vérification du tag AEAD — la fonction decrypt de la bibliothèque sous-jacente renvoie déjà un échec sans révéler quel octet ne correspondait pas ; les implémentations NE DOIVENT PAS réimplémenter cette vérification.
• La vérification de signature — utilisez la fonction verify de la bibliothèque, jamais une équation faite maison.

Un simple == / === sur des tableaux d’octets touchant l’une de ces surfaces est un défaut. Faire transiter chacune de ces comparaisons par un unique helper typé rend la propriété auditable.

La discipline de temps constant s’étend à la forme de la boucle de déchiffrement à l’essai, et pas seulement aux comparaisons individuelles. Pour préserver la propriété de destinataire caché, un vérificateur destinataire DOIT traiter tous les slots au sein de la passe d’une seule clé privée — un nombre constant d’opérations de slot par clé, sans sortie anticipée à la première correspondance — de sorte qu’un observateur au niveau réseau ayant accès aux temps ne puisse pas inférer quel indice de slot une clé a déballé, ni si l’une d’elles l’a fait. La clé candidate est sélectionnée à temps constant. La validité du secret partagé X25519 est captée par un bit indépendant du secret, kem_ok = NOT constantTimeEqual(shared, 0^32), calculé avec une comparaison à temps constant plutôt qu’une branche anticipée ; la KEK est alors une sélection à temps constant entre la KEK réelle et une KEK factice dérivée d’un secret partagé entièrement nul sous les mêmes salt et info, et kem_ok est intégré à l’acceptation du slot (ok = kem_ok AND open_ok AND mac_ok) de sorte qu’un slot à ECDH invalide ne puisse jamais être accepté tandis que la boucle exécute toujours un travail identique. Le tableau de slots est publié dans un ordre mélangé par CSPRNG, de sorte que la position sur le wire ne véhicule déjà aucun signal « destinataire principal d’abord » ; combiné à la passe à temps constant, un observateur n’apprend que le nombre de slots. Un destinataire détenant plusieurs clés privées (par exemple des clés archivées au fil d’une rotation d’identité) itère clé × slot et PEUT court-circuiter entre les clés — cela ne laisse fuir que le faible signal « quelle clé a correspondu » — mais DOIT rester à temps constant à travers les slots de toute clé individuelle, en redérivant par clé la moitié du salt de la KEK correspondant à la clé du destinataire, puisque les deux KEM engagent le salt sur l’encodage wire canonique de cette clé (exactement la clé publique X25519 de 32 octets, ou exactement les octets fixés de 1216 octets de la clé publique X-Wing — jamais un réencodage non canonique).

Vérification stricte d’Ed25519

Les signatures Label 309 DOIVENT être vérifiées en mode strict (canonique). Un vérificateur laxiste, avec cofacteur, accepte certaines signatures malléables ou à clés d’ordre faible qu’un vérificateur strict rejette, ce qui permettrait à deux implémentations conformes de diverger sur le même enregistrement — brisant la propriété de verdict unique dont dépend l’ensemble du standard. Le corpus de conformité multilangage fixe exactement un vecteur de test à ordre faible pour attraper un vérificateur qui aurait glissé en mode laxiste. Voir Signatures.

Ne jamais journaliser de matériel secret

Les octets de seed, les clés privées dérivées, les clés de chiffrement de clé, les clés de chiffrement de contenu, le matériel dérivé d’une phrase secrète et le texte en clair déchiffré NE DOIVENT PAS atteindre les journaux à quelque niveau que ce soit. Le caviardage fondé sur les chemins dans la configuration d’un journaliseur est nécessaire mais pas suffisant à lui seul : une valeur imbriquée plus profondément que ne porte le glob de caviardage peut passer entre les mailles, de sorte que les implémentations DOIVENT en outre traiter chaque valeur de type octet (Uint8Array, bytes et assimilés) comme caviardée de façon opaque et sans condition, même pour des valeurs publiques du protocole comme un nonce. Le secret le moins coûteux à protéger est celui qui n’entre jamais dans une ligne de journal.

Garanties de construction de la PoE scellée

Trois propriétés supplémentaires sont spécifiques à la construction de la PoE scellée. Elles sont normatives en matière de sécurité pour toute implémentation qui produit ou ouvre un enregistrement scellé.

Le MAC de l’ensemble de slots est un engagement d’environ 128 bits

Le MAC de l’ensemble de slots est ce qui fait d’une clé de contenu recouvrée un engagement sur l’ensemble de slots auquel le destinataire a correspondu : un expéditeur malveillant ne peut pas construire deux ensembles de slots distincts qu’un même destinataire accepte tous deux comme « les siens ». La propriété requise est l’engagement de clé restreint pour la clé de contenu de l’enveloppe, au sens de la RFC 9771 — la clé recouvrée se lie à une unique transcription de slots — et non un AEAD pleinement engageant sur des entrées arbitraires. Le destinataire dérive une clé d’un slot, puis exige que cette même clé reproduise slots_mac sur l’empreinte de la transcription de slots avant de traiter le slot comme le sien. Concrètement, l’engagement repose sur la résistance aux collisions multiclés de

CEK ↦ HMAC-SHA-256( HKDF-SHA-256(CEK, info="cardano-poe-slots-mac-v1"), slots_hash )

pour des CEK et des transcriptions choisis par l’adversaire. Comme l’adversaire contrôle à la fois la CEK et la transcription, la borne pertinente est celle de la collision générique (du paradoxe des anniversaires) sur la sortie HMAC de 256 bits : trouver deux paires (CEK, transcript) produisant le même slots_mac est une recherche d’environ 128 bits, non le niveau de seconde préimage de 256 bits. Une marge de collision générique de 128 bits est le niveau de sécurité sur lequel cet engagement repose, et il est adéquat pour le modèle de menace.

Pré-hacher la transcription en un slots_hash de 32 octets avant le HMAC ne l’affaiblit pas : une collision de slots_mac implique soit une collision de slots_hash (une collision SHA-256), soit une collision du HMAC à clé sur des slots_hash égaux, toutes deux au niveau d’environ 128 bits. La résistance à la falsification de la transcription elle-même hérite de la borne de collision 2^128 de SHA-256 : tout changement d’un champ d’en-tête engagé ou d’un octet de slot altère slots_hash, et forger un slots_hash inchangé sur une transcription différente est exactement cette recherche de collision d’environ 128 bits. Une conséquence directe est que l’enveloppement par slot n’a pas besoin d’être un AEAD engageant : l’engagement est fourni par slots_mac, non par l’enveloppement, de sorte qu’un enveloppement non engageant (le ChaCha20-Poly1305 par défaut) est sain ici.

La sûreté de l’enveloppement à nonce nul repose sur l’unicité de clé par slot

Chaque slot enveloppe la clé de contenu sous une clé de chiffrement de clé propre au slot avec ChaCha20-Poly1305 à un nonce nul. Un nonce nul n’est sûr que parce que la clé de chiffrement de clé est propre au slot et utilisée pour exactement un enveloppement : chaque slot puise un aléa KEM frais, de sorte que la clé d’enveloppement est unique par slot avec une probabilité de collision négligeable. La condition de sûreté est exactement l’unicité de clé par slot, et un producteur NE DOIT PAS introduire quoi que ce soit qui pourrait répéter une paire (key, nonce) — une défaillance du CSPRNG répétant l’aléa KEM, une encapsulation déterministe ou en collision, la réutilisation d’un slot d’un enregistrement à l’autre, la mise en cache d’une clé dérivée par (recipient, ephemeral), ou la déduplication de deux occurrences du même destinataire en un seul slot.

Cela se scinde nettement en une part vérifiable par le vérificateur et une obligation propre au producteur :

• Les doublons au sein d’un enregistrement sont rejetés par le vérificateur. Un vérificateur DOIT exiger que le matériel d’encapsulation soit distinct au sein d’un même slots[] — toutes les valeurs epk distinctes sur le chemin x25519, toutes les valeurs kem_ct distinctes sur le chemin mlkem768x25519. Un doublon est rejeté avant l’exécution de toute primitive KEM ou AEAD, avec le code typé ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Le corpus de conformité exerce ce cas avec un enregistrement portant deux slots qui partagent un epk (ou un kem_ct) et exige ce rejet. Ce rejet ne se déclenche que sur un epk / kem_ct répété ; il n’interdit pas de sceller deux fois vers le même destinataire, puisque la duplication honnête puise tout de même un aléa KEM frais par slot à chaque occurrence (voir la règle des slots multiples correspondants ci-dessous).
• La réutilisation entre enregistrements et entre clés est une obligation du producteur. Aucun vérificateur ne peut détecter qu’un producteur a réutilisé du matériel KEM d’un enregistrement ou d’un destinataire à l’autre ; cela se situe hors des octets d’un enregistrement isolé et demeure une responsabilité du producteur. Si une révision future venait à permettre la réutilisation de clés, le nonce nul devrait être remplacé par un nonce frais dans la même modification.

Slots multiples correspondants : le remplissage est permis, un conflit de CEK ne l’est pas

La clé privée d’un destinataire PEUT légitimement correspondre à plus d’un slot. Sceller la même clé de contenu vers le même destinataire dans plusieurs slots — chacun avec des éphémères frais par slot — est une technique valide de remplissage et de confidentialité, qui augmente le nombre de slots visible sans révéler que deux des slots partagent un destinataire. Elle est distincte du rejet du doublon d’encapsulation au sein de l’enregistrement ci-dessus : la duplication honnête puise un aléa KEM frais, de sorte que ses epk / kem_ct diffèrent et qu’elle ne déclenche jamais ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Un vérificateur DOIT donc sélectionner la clé de contenu du premier slot correspondant et NE DOIT PAS rejeter au seul motif que plus d’un slot a correspondu.

La seule anomalie qu’un vérificateur DOIT rejeter est constituée de deux slots correspondants qui recouvrent des clés de contenu différentes, comparées à temps constant. La boucle de déchiffrement à l’essai porte un bit cek_conflict à travers tous les slots et fait remonter l’unique échec générique si une correspondance ultérieure recouvre une clé qui diffère de celle déjà sélectionnée. Il s’agit de défense en profondeur : sous la propriété d’engagement ci-dessus, une correspondance à clé distincte est déjà infaisable — c’est exactement la collision multiclé que cette propriété exclut — de sorte que la vérification échoue de façon sûre face à une implémentation défectueuse ou à un affaiblissement futur de l’hypothèse. Le négatif à clé distincte n’est pas constructible sous forme de vecteur d’octets (en construire un serait la collision d’engagement elle-même), de sorte que la propriété est fixée par des tests comportementaux au niveau de l’implémentation plutôt que par une fixture, aux côtés d’une fixture positive pour la duplication légitime de destinataire.

Bornes de ressources de l’analyseur avant toute primitive

Un vérificateur DOIT borner l’usage des ressources de l’analyseur avant d’invoquer toute primitive KEM ou AEAD, de sorte qu’une enveloppe surdimensionnée ne puisse pas imposer de travail avant d’être rejetée. Les bornes de référence sont MAX_SLOTS = 1024 slots et 65536 octets pour l’enveloppe enc décodée — toutes deux bien au-dessus du plafond d’environ 16 KiB des métadonnées de transaction Cardano qui contraint tout enregistrement honnête, de sorte qu’un enregistrement dépassant l’une ou l’autre borne est malformé. Un dépassement de compte est rejeté avec ENC_SLOTS_TOO_MANY, une enveloppe surdimensionnée avec ENC_ENVELOPE_TOO_LARGE. Ce sont des constantes appliquées par le vérificateur et fixées par déploiement — non des champs du wire — et un déploiement PEUT les resserrer. La garde analogue sur le chemin de la phrase secrète est une longueur maximale d’entrée brute de phrase secrète appliquée avant la normalisation et Argon2id (borne de référence 4096 octets UTF-8, MAX_PASSPHRASE_INPUT_BYTES), de sorte qu’une phrase secrète pathologique ne puisse pas provoquer un déni de service pré-KDF.

La validité de la clé publique X-Wing borne le plancher hybride

Le KEM hybride mlkem768x25519 ne descend jamais sous la sécurité classique de X25519 comme plancher — mais ce plancher est circonscrit aux clés de destinataire générées validement. XWing.Encapsulate DOIT appliquer la vérification de validité de clé publique de la révision X-Wing fixée à la clé du destinataire et refuser d’encapsuler vers une clé qui ne la passe pas, plutôt que de traiter une clé malformée comme si elle portait la garantie classique. Un producteur qui saute la vérification renonce au plancher pour ce destinataire ; la vérification est la précondition sous laquelle le plancher tient.

Taille de charge utile bornée

La couche de contenu est un STREAM segmenté : le texte en clair est découpé en fragments de 65536 octets, chacun scellé sous la clé de contenu avec un nonce de compteur distinct. Le compteur par fragment de 88 bits admet 2^88 fragments et chaque fragment reste largement dans la limite d’invocation unique de RFC 8439, de sorte que — contrairement à un AEAD en une seule passe sur l’ensemble du texte en clair — il n’y a aucune collision de flux de clé par débordement de compteur contre laquelle se prémunir et le format n’impose aucun plafond cryptographique à la charge utile. Le maximum qu’un déploiement fait respecter est donc une politique de déni de service, non une borne cryptographique : les producteurs et les vérificateurs DEVRAIENT plafonner la taille de la charge utile pour qu’elle tienne dans leurs ressources et l’appliquer de façon incrémentale à mesure que le flux est écrit ou lu, en interrompant avant qu’une charge utile surdimensionnée ne soit mise en tampon. La troncature est détectée structurellement par le drapeau de fin de chaque fragment — un fragment final manquant, des données en trop ou un fragment non final trop court font échouer le déchiffrement — plutôt que par une vérification de taille. La posture est identique sur le chemin des slots et sur le chemin de la phrase secrète.

L’agilité algorithmique comme propriété de sécurité

Chaque choix cryptographique dans un enregistrement Label 309 est nommé par une chaîne issue d’un registre extensible — l’empreinte, l’AEAD, le KEM, le KDF, le schéma de signature. Ce n’est pas un choix stylistique ; c’est le substrat de migration qui permet au format de survivre à n’importe quel algorithme isolé.

Si une primitive est affaiblie par la cryptanalyse :

1. Le registre concerné acquiert un identifiant successeur. Rien dans le format existant ne change — le nouveau nom est additif.
2. Les enregistrements existants restent valides. Un vérificateur continue de reconnaître l’ancien identifiant pour les enregistrements historiques ; leurs affirmations d’heure de bloc ne s’évaporent pas parce qu’un algorithme plus récent existe. Une implémentation PEUT présenter un enregistrement qui ne repose que sur un algorithme depuis lors affaibli comme étant de moindre assurance, mais NE DOIT PAS l’effacer ni le rejeter sur cette seule base.
3. Les nouveaux enregistrements se publient sous le successeur. Un producteur qui veut une défense en profondeur PEUT engager une empreinte de contenu sous deux algorithmes de familles de conception distinctes, de sorte qu’une rupture d’une seule famille n’effondre pas la valeur probante de l’enregistrement — bien que les enregistrements à un seul algorithme restent pleinement conformes.

Parce que les identifiants sont des chaînes et que les registres sont ouverts, migrer vers des empreintes, des KEM ou des signatures post-quantiques est une modification de registre additive, jamais une révision de format qui rompt la compatibilité. Le KEM hybride post-quantique déjà présent dans le registre est une instance de cette propriété en action, non un cas particulier ajouté après coup.

Limites connues du standard

Ce ne sont pas des défauts à corriger dans une révision ultérieure ; ce sont des propriétés inhérentes au fait d’ancrer des preuves sur un registre public permanent et au chiffrement à clé publique vers des clés à long terme. Un modèle de sécurité honnête les nomme.

Permanence sur la chaîne

Les métadonnées Cardano sont permanentes et répliquées mondialement. Un enregistrement Label 309 publié ne peut être ni supprimé, ni caviardé, ni invalidé — cette durabilité est tout l’objet de la preuve d’existence. La conséquence est une responsabilité au moment de la publication : une empreinte de contenu, une signature liée à un stake, ou toute autre chose engagée sous le label 309 est sur la chaîne pour toujours. Label 309 omet délibérément de l’enregistrement les métadonnées descriptives en format libre afin de garder l’empreinte sur la chaîne minimale, mais un producteur DOIT comprendre que ce qu’il publie est irrévocable avant de le publier.

Le nombre de destinataires est visible

Une PoE scellée ne nomme jamais ses destinataires, mais le nombre de slots de destinataire est la longueur du tableau, clairement visible sur la chaîne — tout comme la famille de KEM (enc.kem) et la distinction entre scellé et ouvert. Les clés publiques des destinataires sont hors du wire et les slots sont mélangés, mais le remplissage masquant le compte ne fait pas partie de la ligne de base. Un expéditeur pour qui le nombre de destinataires est lui-même sensible doit tenir compte de cette fuite de métadonnées de façon opérationnelle — par exemple en remplissant lui-même l’ensemble de slots, ou en publiant des enregistrements distincts.

Aucune révocation par destinataire

Il n’existe aucune primitive sur la chaîne pour révoquer l’accès d’un seul destinataire à une PoE scellée déjà publiée. Une fois qu’un enregistrement est chiffré vers une clé publique et ancré, ce lien est permanent. C’est une propriété inhérente au chiffrement à clé publique vers une clé à long terme, et non une lacune du format. Une clé que l’on croit compromise se gère vers l’avant — en adressant les nouveaux enregistrements à une clé fraîche, en publiant facultativement un enregistrement de remplacement à titre de signal d’avertissement — jamais en revenant en arrière pour altérer ce qui est déjà sur la chaîne.

Aucune confidentialité persistante pour le destinataire, par conception

Le détenteur d’une clé privée de destinataire peut déchiffrer, à jamais, toute PoE scellée qui lui a été adressée. Le texte chiffré hors chaîne est permanent et il n’y a aucune primitive de révocation, de sorte qu’un enregistrement scellé est privé vis-à-vis du monde mais pas vis-à-vis de son destinataire. C’est le comportement attendu du chiffrement vers une clé publique à long terme. Un expéditeur qui a besoin de limiter la portée future d’un destinataire doit chiffrer vers une clé de destinataire à courte durée de vie plutôt qu’une clé d’identité à long terme — un choix côté expéditeur que le format permet mais n’impose pas.

Les échecs du déchiffrement à l’essai ne laissent fuir aucun matériel de clés

Un destinataire découvre son slot par déchiffrement à l’essai. En interne — aux seules fins de diagnostic d’un appelant local de confiance — les chemins d’échec portent des codes typés distincts : « aucun slot ouvert avec ma clé » (WRONG_RECIPIENT_KEY), « un slot s’est ouvert mais aucune clé candidate n’a reproduit slots_mac » (TAMPERED_HEADER), et « l’AEAD de contenu a échoué après qu’une clé a été recouvrée et le MAC vérifié » (TAMPERED_CIPHERTEXT). Ces codes ne portent aucune valeur d’oracle : un adversaire sans clé privée correspondante n’ouvre aucun slot, et chaque chemin d’erreur DOIT exclure de son message et de sa chaîne de causes les octets secrets sous-jacents (le secret partagé, la clé de chiffrement de clé, la clé de chiffrement de contenu).

Un appelant externe non fiable, en revanche, DOIT recevoir exactement une seule forme d’échec générique quelle que soit la raison de l’échec du déchiffrement, et la réponse externe NE DOIT PAS distinguer les trois causes par sa forme, ni révéler quel slot a correspondu. Les codes internes existent pour le débogage local ; ils NE DOIVENT PAS fuiter vers un observateur extérieur à travers une réponse distinguable.

Le modèle de temporisation est délibérément circonscrit. Un vérificateur PEUT retourner à la vérification de non-correspondance, avant le déchiffrement du contenu — de sorte qu’un non-destinataire (aucun slot ouvert) puisse être chronométré à part d’un destinataire dont le slot s’est ouvert mais dont le texte chiffré de contenu n’arrive pas à s’ouvrir. Cette distinction ne révèle que destinataire versus non-destinataire ; elle ne révèle jamais quel slot a correspondu, ni aucun matériel de clé. Une temporisation uniforme entre le cas du non-destinataire et le cas du texte chiffré défectueux N’EST PAS requise, et une ouverture de contenu factice NE DOIT PAS être imposée — forcer le coût du déchiffrement de contenu sur chaque non-destinataire n’apporterait rien. La garantie de temps constant qui tient bel et bien est l’invariant à travers les slots (voir Comparaison de secrets à temps constant) : au sein de la passe d’une seule clé, la boucle parcourt tous les slots avec des comparaisons à temps constant, de sorte qu’un observateur ne peut pas apprendre quel slot, le cas échéant, une clé donnée a déballé — et au-delà de la distinction destinataire-versus-non, n’apprend que le nombre de slots.

Pages associées

• Introduction — les cinq invariants, dont l’indépendance vis-à-vis de l’émetteur et la vérifiabilité autonome.
• Signatures — la vérification stricte d’Ed25519 et le modèle de paternité à dégradation douce.
• PoE scellée — l’enveloppe de chiffrement et les propriétés de confidentialité résumées ici.
• Registres d’algorithmes — les identifiants nommés qui rendent l’agilité algorithmique possible.
• Vérification — le pipeline, la politique de profondeur de confirmation et le catalogue des erreurs.