supermagnum/cessSecret de Shamir Enchanté Cryptologiquement
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).
Les écosystèmes existants couvrent des parties de ce problème mais laissent des lacunes :
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.
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).
