Registres d’algorithmes

Chaque choix cryptographique dans Label 309 est désigné par un identifiant textuel tiré d’un registre extensible : sha2-256, chacha20-poly1305-stream64k, EdDSA, etc. Un enregistrement ne porte jamais un numéro d’algorithme brut ni une hypothèse implicite ; il déclare quelle primitive il a utilisée, et un vérificateur recherche cet identifiant. C’est le mécanisme qui sous-tend l’invariant agile vis-à-vis des algorithmes : les registres peuvent croître avec le temps, et un vérificateur qui rencontre un identifiant qu’il n’implémente pas rejette l’enregistrement avec une erreur typée et stable — il ne plante jamais, et il n’accepte jamais en silence quelque chose qu’il ne peut pas vérifier.

Cette seule règle est ce qui rend additive la migration vers les algorithmes post-quantiques. Un nouvel identifiant est une nouvelle ligne dans une table, non une nouvelle version du format de sérialisation (wire format). Les enregistrements anciens continuent de se vérifier exactement comme avant, et les vérificateurs anciens échouent de manière sûre face aux enregistrements qu’ils n’ont jamais été conçus pour comprendre.

Hachage

L’empreinte du contenu est l’affirmation principale de tout enregistrement, si bien que le registre des empreintes est celui qui porte le plus de poids. Les deux fonctions enregistrées produisent un condensé de 32 octets, et toutes deux sont obligatoires à prendre en charge pour une implémentation conforme.

Un producteur PEUT calculer l’empreinte du même contenu avec les deux fonctions pour une défense en profondeur ; une seule empreinte suffit pour un enregistrement valide.

Engagement Merkle

Pour s’engager sur une liste ordonnée de feuilles sous une racine unique sur la chaîne, Label 309 enregistre un identifiant d’engagement Merkle. C’est la chaîne enregistrée par l’IANA pour l’arbre de Merkle binaire SHA-256, qui partage la séparation de domaines par préfixe de feuille (0x00) et préfixe de nœud interne (0x01) qui empêche les collisions entre feuilles et nœuds.

Un arbre à une seule feuille s’engage sur SHA-256(0x00 ‖ leaf), non sur la feuille nue — c’est pourquoi une preuve sur un seul fichier DOIT utiliser un identifiant d’empreinte simple, jamais un arbre à 1 feuille.

AEAD

Le registre AEAD régit quel format de contenu protège une charge utile scellée sur le fil — le champ enc.aead. Exactement un identifiant est enregistré sous enc.scheme: 1, et il s’agit d’un format segmenté plutôt que d’un chiffreur à passe unique.

chacha20-poly1305-stream64k est ChaCha20-Poly1305 (RFC 8439) dans la disposition STREAM segmentée de 64 KiB de la spécification age v1 : le texte en clair est découpé en segments de 65536 octets, et chaque segment est scellé sous la clé de contenu avec un nonce par segment de 12 octets uint88_be(counter) ‖ final_flag (compteur à partir de 0, final_flag 0x01 sur le dernier segment) et un AAD par segment vide, produisant une étiquette de 16 octets par segment. Le enc.nonce de 24 octets n’est pas un nonce de segment : c’est le sel unique par enveloppe du HKDF de la clé de contenu, ce qui maintient la sûreté des nonces de compteur — la clé de contenu est à usage unique, de sorte que deux flux ne partagent jamais une paire (key, nonce) et que les producteurs sans état ne coordonnent jamais les nonces d’une enveloppe à l’autre. La disposition segmentée permet à un vérificateur d’authentifier et de libérer une charge utile volumineuse de manière incrémentale avec une mémoire bornée, et le marqueur final rend la troncature détectable. La graphie sur le fil est exactement chacha20-poly1305-stream64k ; des graphies alternatives NE DOIVENT PAS être produites. La construction complète figure sur PoE scellée.

chacha20-poly1305-stream64k est le seul identifiant qui puisse apparaître comme format de contenu sur le fil. Une construction distincte, chacha20-poly1305 (RFC 8439, clé de 32 octets / nonce de 12 octets / étiquette de 16 octets), est utilisée en interne pour envelopper une clé par destinataire au sein de la construction scellée : un nonce de 12 octets entièrement à zéro, l’AAD fixée à l’étiquette info du KEM choisi, produisant un wrap de 48 octets (clé enveloppée de 32 octets + étiquette de 16 octets). C’est un bloc de construction, non un identifiant de fil, et un enregistrement qui le nomme dans enc.aead DOIT être rejeté. aes-256-gcm est nommé mais inactif ; il est réservé à un profil de chiffrement futur (enc.scheme: 2) et un vérificateur v1 rejette tout enregistrement qui le sélectionne.

KEM

Le registre KEM couvre les mécanismes d’encapsulation de clé utilisés pour adresser une charge utile scellée à des destinataires précis. Label 309 enregistre un KEM classique sur courbe et un hybride post-quantique qui est distribué actif dès la première version.

mlkem768x25519 est la construction X-Wing de draft-connolly-cfrg-xwing-kem-10 : elle apparie ML-KEM-768 (FIPS 203) à X25519 (RFC 7748) de sorte qu’un attaquant doive briser les deux pour récupérer le secret partagé. La clé publique est la clé d’encapsulation ML-KEM-768 concaténée avec la clé publique X25519 (1184 o ‖ 32 o = 1216 o) ; le secret est un seed de 32 octets à partir duquel la clé complète est dérivée. Le texte chiffré de chaque destinataire est le texte chiffré ML-KEM-768 concaténé avec une clé publique X25519 éphémère (1088 o ‖ 32 o = 1120 o), et les deux secrets partagés sont combinés par le combinateur SHA3-256 de X-Wing (FIPS 202) pour obtenir le secret final de 32 octets. Label 309 consomme X-Wing comme un KEM en boîte noire — encapsuler, désencapsuler, le secret partagé de 32 octets — et ne s’appuie sur aucune propriété du hachage interne du combinateur. L’identifiant est écrit sans traits d’union internes pour coïncider avec la graphie établie de X-Wing.

L’hybride est sélectionné par enregistrement au moyen de l’en-tête de chiffrement, indépendamment de l’AEAD de contenu. Comme il est déjà enregistré, la confidentialité post-quantique est affaire de choisir l’identifiant — non d’attendre une nouvelle version du format de sérialisation.

Un même enregistrement nomme exactement un enc.kem, et chaque emplacement utilise la forme de ce KEM ; un emplacement de la mauvaise forme est ENC_SLOT_INVALID_SHAPE, un epk (≠ 32 o) ou un kem_ct (≠ 1120 o) de longueur incorrecte est KEM_EPK_LENGTH_MISMATCH / KEM_CT_LENGTH_MISMATCH, et un enc.kem non enregistré est UNSUPPORTED_KEM_ALG. Le matériel d’encapsulation doit également être distinct au sein d’un même slots[] : toutes les valeurs epk (pour x25519) ou toutes les valeurs kem_ct (pour mlkem768x25519) DOIVENT différer. Un doublon au sein de l’enregistrement est rejeté avec ENC_SLOTS_DUPLICATE_KEM_MATERIAL avant l’exécution de toute primitive KEM ou AEAD, car un epk ou un kem_ct répété rompt l’unicité de la clé par emplacement dont dépend l’enveloppement à nonce nul. Un vérificateur borne aussi l’usage des ressources de l’analyseur avant toute primitive : une enveloppe dont les slots[] dépassent la borne de référence de 1024 emplacements est ENC_SLOTS_TOO_MANY, et une enveloppe enc décodée dépassant 65 536 octets est ENC_ENVELOPE_TOO_LARGE. Les deux bornes se situent très au-dessus du plafond de ~16 KiB des métadonnées Cardano qui borne tout enregistrement honnête ; ce sont des constantes imposées par le vérificateur et fixées par déploiement — non des champs de fil — et les déploiements PEUVENT les resserrer.

KDF

Le registre KDF nomme les fonctions de dérivation de clé. hkdf-sha256 dérive des clés au sein de la construction scellée ; argon2id renforce une phrase secrète humaine contre la force brute et porte un plancher de paramètres obligatoire.

Le plancher Argon2id est normatif : une charge utile protégée par phrase secrète DOIT utiliser au moins 64 MiB de mémoire, au moins trois itérations et au moins une voie (lane). Un producteur PEUT choisir des paramètres plus forts, et ceux-ci voyagent avec l’enregistrement afin qu’un vérificateur puisse reproduire la dérivation. Là où la plateforme le permet, les producteurs DEVRAIENT fixer le parallélisme p = 4 — le second profil recommandé par la RFC 9106 §4 — tandis qu’un vérificateur PEUT accepter n’importe quel p ≥ 1, sous réserve des plafonds du déploiement. Ces plafonds relèvent d’un DEVRAIT d’implémentation, non d’un PEUT : un vérificateur DEVRAIT imposer des bornes supérieures contre un déni de service côté vérificateur dû à des paramètres absurdes, en signalant ENC_PASSPHRASE_PARAMS_EXCEED_POLICY. Le plafond dépend du matériel et n’est pas normatif, et NE DOIT PAS être confondu avec le code de plancher ENC_PASSPHRASE_ARGON2_PARAMS_TOO_LOW.

Seul argon2id est sélectionnable sur le fil : c’est le seul identifiant qu’un enregistrement puisse nommer dans enc.passphrase.alg. hkdf-sha256 est un bloc de construction interne — c’est l’étape fixe d’extraction et d’expansion derrière la dérivation du seed vers la clé, la dérivation du KEK par emplacement, la clé MAC de l’ensemble des emplacements, la clé MAC de l’engagement de phrase secrète et la dérivation de la clé de contenu — et il ne porte aucun identifiant de fil. Un enregistrement qui nomme hkdf-sha256 dans enc.passphrase.alg DOIT être rejeté : HKDF est conçu pour des entrées à forte entropie, non pour étirer une phrase secrète à faible entropie.

Les étiquettes internes sont des constantes, jamais sur le fil

La construction scellée tire sa séparation de domaines d’un ensemble fixe de littéraux d’étiquette — des balises info de HKDF et des préfixes SHA-256 (préfixes de sel de KEK, préfixes de transcription et le préfixe d’empreintes d’éléments). Chacun est une constante de enc.scheme: 1, ASCII exact sans terminateur ni préfixe de longueur ; aucun n’est jamais sérialisé, et aucun n’est sélectionnable à travers un quelconque registre. Il y en a onze :

Les deux sels de KEK partagent une seule forme de hachage étiqueté — SHA-256(label ‖ enc.nonce ‖ <matériel KEM de l’emplacement> ‖ pub_R) — sous leur propre étiquette par KEM. Ces étiquettes sont distinctes des chaînes info de dérivation du seed sur Clés et du préfixe de domaine de signature d’enregistrement sur Signatures : l’ensemble est sans collisions et sans préfixes, de sorte qu’aucune étiquette scellée par enregistrement n’est égale à — ni n’est un préfixe d’octets de — une étiquette de dérivation de clé à long terme, et la dérivation de la clé d’identité et l’enveloppement de clé par enregistrement ne se télescopent jamais. Un vérificateur DOIT utiliser chaque littéral octet par octet ; un seul octet divergent produit un slots_mac, un engagement ou une étiquette AEAD que le producteur honnête ne peut pas reproduire. La construction au niveau des octets qui consomme chaque étiquette figure sur PoE scellée.

Signature

Label 309 enregistre un seul algorithme de signature. Les signatures de paternité sont toujours facultatives, mais lorsqu’elles sont présentes elles sont transportées sous forme de COSE_Sign1 (RFC 9052) à l’aide d’Ed25519.

La vérification est stricte selon RFC 8032 §5.1.7 : les implémentations DOIVENT rejeter les encodages de signature non canoniques et les points d’ordre petit (sans extension d’élimination du cofacteur). Cela coïncide avec les critères d’acceptation conservateurs employés à travers les portefeuilles Cardano, de sorte qu’une signature qui se vérifie sous une implémentation conforme se vérifie sous toutes.

La prise en charge des signatures est indépendante de l’affirmation de contenu. Un vérificateur qui n’implémente pas l’algorithme de signature d’un enregistrement marque cet emplacement de signature comme non pris en charge et laisse les affirmations d’horodatage et de contenu pleinement valides — un algorithme de signature inconnu n’invalide jamais l’enregistrement lui-même.

Identifiants réservés

Plusieurs identifiants sont nommés mais pas encore actifs. Ils balisent le chemin de migration convenu afin que les profils futurs utilisent des noms stables et engagés à l’avance plutôt que des chaînes improvisées. Un producteur conforme NE DOIT PAS les émettre, et un vérificateur conforme DOIT rejeter tout enregistrement qui en utilise un, avec l’erreur typée correspondante.

ml-kem-768 est le KEM post-quantique nu, distinct de l’hybride enregistré mlkem768x25519 ; c’est l’hybride que Label 309 met en service, selon le principe qu’un repli classique doit subsister même après l’ajout de la moitié post-quantique.

Agilité des algorithmes et migration

Ajouter un algorithme est une opération autonome et additive : citez un standard public pour la primitive, ajoutez l’identifiant au registre approprié, fournissez-en une implémentation vérifiée et bien revue, et publiez un fixture de conformité multilangage afin que des implémentations indépendantes concordent octet par octet. La version du format de sérialisation ne change pas, parce que le schéma ne change pas — seul l’ensemble des chaînes reconnues croît.

Les conséquences découlent directement de la conception des registres :

• Les anciens enregistrements restent vérifiables. Leurs identifiants sont toujours dans le registre, si bien que chaque enregistrement existant se vérifie exactement comme le jour où il a été publié.
• Les anciens vérificateurs échouent de manière sûre. Un vérificateur antérieur à un nouvel identifiant rejette les enregistrements qui l’utilisent avec une erreur stable UNSUPPORTED_* plutôt que de deviner — il n’existe aucune voie vers une acceptation silencieuse.
• La prise en charge post-quantique est additive. Parce que mlkem768x25519 est déjà enregistré, et parce que les nouveaux KEM et signatures s’insèrent dans le même mécanisme, la transition post-quantique est une croissance du registre, non une migration cassante.

Une montée de version du format de sérialisation est réservée aux changements de schéma véritablement cassants — un nouveau champ obligatoire, un champ supprimé, un type modifié. La croissance du registre ne remplit jamais ce critère, ce qui est précisément ce qui permet au catalogue cryptographique d’évoluer sans jamais laisser en rade une preuve déjà publiée.