CESS — Secret de Shamir enchanté cryptologiquement

Est-ce que c'est de l'IA bullshit ou du slop ?

Un cryptographe ou un implémenteur sérieux examinant CESS ouvrira généralement vectors/ et testdata/ avant de lire la prose. La suite de tests est la preuve de travail : elle encode une connaissance du domaine qui ne peut être remplacée par un simple récit.

Ce n'est pas une raison pour cacher l'essentiel à tous les autres. Les personnes qui évaluent le projet pour un achat, qui décident d'y contribuer, qui rédigent des politiques, ou qui livrent du code sans formation approfondie à la méthodologie de test cryptographique méritent tout de même une indication vers les preuves concrètes. Le dépôt énonce déjà les règles d'audit et les exclusions d'algorithmes ; relier cette histoire aux vecteurs de test publiés comble l'écart entre « les affirmations sur la page » et « les artefacts que vous pouvez exécuter. »

Ce qu'il faut regarder : Le matériel de conformité comprend des exemples travaillés RFC 8439 pour ChaCha20-Poly1305 (l'AEAD IETF que ce projet référence normativement) et le JSON Wycheproof importé pour les cas limites de ChaCha20-Poly1305 sous testdata/wycheproof/. Avec les vecteurs TOML propres au projet dans vectors/, ils constituent la vérité de terrain que l'exécuteur et les relecteurs peuvent exercer.

RFC 8439 est publié par l'Internet Engineering Task Force (IETF), l'organisation qui normalise une grande partie de l'interopérabilité d'Internet. Les RFC (Request for Comments) sont la forme habituelle pour les spécifications de protocoles et de nombreuses spécifications cryptographiques. RFC 8439 définit le chiffrement authentifié ChaCha20-Poly1305 (basé sur les conceptions de Daniel Bernstein) et inclut des exemples travaillés concrets avec des entrées spécifiques et des sorties attendues afin que les implémentations indépendantes puissent vérifier qu'elles correspondent au standard octet par octet. Le texte en clair largement reproduit commençant par Ladies and Gentlemen of the class of '99: wear sunscreen apparaît dans les exemples en annexe de la RFC : si votre code reproduit exactement la sortie AEAD, vous avez une vérification solide que vous avez implémenté la construction correctement. C'est l'analogue cryptographique d'un corrigé officiel. (La RFC 7539 antérieure documentait ChaCha20 et Poly1305 pour d'autres contextes IETF ; RFC 8439 est la référence habituelle pour cet AEAD tel qu'utilisé ici et dans spec/CESS-v0.2.md.)

Wycheproof est un corpus de test publié par l'équipe de sécurité de Google (2017). Le nom fait référence au Mont Wycheproof en Australie — souvent cité comme la plus petite montagne du monde — car le projet se concentre sur le franchissement de petits mais fatals obstacles : débordements d'entiers, cas limites, entrées mal formées et étiquettes d'authentification falsifiées ; des échecs qui apparaissent de manière répétée dans la crypto déployée en conditions réelles. Il complète les vecteurs de style RFC : les exemples de type RFC 8439 démontrent l'exactitude par rapport à l'AEAD publié ; Wycheproof teste la robustesse là où les implémentations échouent historiquement.

Ce que cela dit de ce standard est laissé à l'appréciation du lecteur bien informé.

On peut également vérifier l'intégrité des crates avec ceci lorsque la PR sera fermée : https://github.com/rust-lang/cargo/issues/16850

Version : 0.2
Statut : Spécification uniquement (texte normatif et vecteurs de test)

Ce projet est enregistré auprès de l'Open Invention Network (OIN), un pool de brevets défensif protégeant les logiciels open source liés à Linux. La combinaison d'une publication préimprimée ouverte (établissant un art antérieur), d'une adhésion à l'OIN et d'une licence GPL-3.0 vise à garantir que cette technologie reste librement disponible et ne puisse être propriétisée ou restreinte par aucun État ou acteur commercial.

CESS est un standard cryptographique ouvert pour le partage de secret à seuil combiné avec un chiffrement authentifié agnostique au chiffrement, un emballage de parts basé sur un mot de passe et un échange de clés hybride post-quantique optionnel. Il est conçu pour les déploiements nécessitant une confidentialité durable, un enrôlement hors ligne, une liaison à des jetons matériels et des voies d'approvisionnement indépendantes des bases d'algorithmes NSA/NIST uniquement.

Les lecteurs non techniques peuvent commencer par le glossaire (termes en langage courant de A à Z).

Pourquoi CESS existe

Les écosystèmes existants couvrent des parties de ce problème mais laissent des lacunes :

• GnuPG fournit un chiffrement et une signature forts, mais pas un profil normatif et interopérable pour les parts Shamir plus l'AEAD moderne et les workflows de dépôt transjuridictionnels.
• Autocrypt se concentre sur le chiffrement opportuniste des courriels, pas sur le fractionnement à seuil de secrets à long terme avec des parts protégées par PIN.
• SLIP-0039 normalise l'encodage mnémotechnique des parts Shamir pour les graines ; CESS complète cet espace avec une enveloppe de part binaire, une négociation explicite de chiffrement, des profils Brainpool ECDH, une gestion de PIN basée sur Argon2id, et des combineurs hybrides CESS-PQ.

CESS définit le standard ; SplitDisk (et les produits similaires) sont des scénarios de référence et des déploiements d'exemple, pas le standard lui-même.

Conception agnostique au chiffrement

CESS fixe le partage secret de Shamir sur GF(2^8) et plusieurs primitives d'intégrité et de mot de passe non optionnelles auditées. Toutes les couches de chiffrement en bloc, KEM, KDF et MAC sont sélectionnables à partir d'un registre audité, sous réserve de la règle des deux auditeurs indépendants et de la liste d'exclusion stricte (voir spec/CESS-v0.2.md et ALGORITHM-REGISTRY.md).

Exigence d'audit et exclusions (résumé)

• Chaque primitive de la couche agnostique doit faire l'objet de deux évaluations indépendantes ou plus provenant de la liste d'auditeurs qualifiés (NESSIE, CRYPTREC, ECRYPT/eSTREAM, comité de lecture IACR, BSI, NCC Group, Cure53, Kudelski Security, JP Aumasson, comité PHC).
• L'apport conceptuel de la NSA, l'examen NIST/FIPS uniquement, et plusieurs algorithmes (AES, SHA-2, SHA-3, courbes NIST, ML-Kyber, Dual_EC_DRBG, RC4, DES, 3DES, HMAC-SHA-*) sont exclus avec une justification explicite dans la spécification.
• X25519 / Ed25519 sont optionnellement autorisés avec une justification documentée (conceptions de Bernstein ; audits indépendants étendus).

Pourquoi les courbes premières NIST (P-256, P-384, P-521) sont omises

Les courbes à corps premier NIST largement utilisées par le gouvernement et l'industrie américains (P-256, P-384, P-521) ont été choisies selon un processus dans lequel la NSA a joué un rôle documenté. CESS ne repose pas sur une preuve mathématique unique que ces courbes sont faibles ; il applique une exclusion politique afin que le standard puisse servir des voies d'approvisionnement, de liaison et d'ingénierie qui exigent une cryptographie justifiée en dehors d'une base NSA/NIST uniquement et qui privilégient les primitives examinées indépendamment (voir spec/CESS-v0.2.md section 3 et ALGORITHM-REGISTRY.md).

L'ECDH classique dans CESS utilise les courbes Brainpool (RFC 5639) à la place. Leurs paramètres sont produits par des règles de génération publiées et elles s'intègrent naturellement dans les discussions alignées sur le BSI et centrées sur l'UE tout en couvrant des cibles de robustesse comparables (par exemple BrainpoolP384r1 vs sécurité de classe P-384) sans adopter la famille de courbes NIST exclue.

Détails : spec/CESS-v0.2.md section 3, spec/CRYPTO.md et ALGORITHM-REGISTRY.md.

Organisation du dépôt

Licences

Brevets et OIN

Les contributeurs acceptent l'engagement de non-contestation des brevets dans PATENTS.md. Le projet est enregistré auprès de l'Open Invention Network (OIN), un pool de brevets défensif pour les logiciels open source liés à Linux. La concession croisée de licences via l'OIN ne couvre pas en soi les parties extérieures à cet écosystème ; l'engagement vise à combler cette lacune pour les implémentations conformes.

Audiences

• Cryptographes et ingénieurs de protocole
• Agences gouvernementales et entrepreneurs de défense (en particulier les achats centrés sur l'UE)
• Vendeurs de jetons de sécurité matériels et de cartes à puce (profil CCID)
• Développeurs open source construisant des outils de garde à seuil et de reprise après sinistre

Contribuer

Voir CONTRIBUTING.md. Les pull requests sont considérées comme une acceptation de PATENTS.md. Les modifications de spécification nécessitent deux relecteurs dans des pays différents. Les nouveaux algorithmes utilisent ALGORITHM-REGISTRY.md (ouvrir une PR contre le registre, puis contre spec/CESS-v0.2.md pour les références croisées si nécessaire).

Ajouter un chiffrement au registre

1. Confirmer deux audits qualifiés et l'absence d'exclusions strictes.
2. Ouvrir une PR modifiant ALGORITHM-REGISTRY.md (tableau de preuves, allocation d'identifiant).
3. Ajouter ou étendre les vecteurs de test sous vectors/ couvrant la nouvelle suite.
4. Obtenir deux relectures de mainteneur selon CONTRIBUTING.md.

Index des documents

• Glossaire (A–Z non technique)
• Standard principal
• CRYPTO (justification)
• GOVERNMENT (déploiement)
• Registre d'algorithmes
• Conformité
• Exécuteur de conformité / cascades internes KAT
• Guide des vecteurs
• Exécuteur de test
• Brevets

Relation avec SplitDisk

CESS est le standard. SplitDisk est un scénario d'implémentation d'exemple (par ex. chiffrement de disque plus distribution de parts) ; la spécification de l'outil réside dans ce dépôt. Les produits peuvent revendiquer une conformité CESS-CORE, CESS-FULL ou CESS-PQ conformément à CONFORMANCE.md sans utiliser le nom SplitDisk.