Auditez le paysage des signatures post-quantiques et des vérifieurs zero-knowledge —— et exécutez un vrai ML-DSA keygen/sign/verify en TypeScript pur.
Ce qui est vérifié :
- Matrice de normes : ML-DSA (FIPS 204 final — pas 203, qui est ML-KEM), SLH-DSA (FIPS 205, 12 jeux), FN-DSA (brouillon FIPS 206, Falcon), signatures BBS (brouillon CFRG, BLS12-381) et les familles ZK Groth16 / PLONK / Halo2 —— tailles exactes de clés/signatures, catégories NIST et IDs COSE/JOSE de la RFC 9964 (-48/-49/-50).
- Audit de trusted setup : cérémonie par circuit (Groth16), SRS Powers-of-Tau universel actualisable (PLONK/KZG) ou rien (IPA transparent de Halo2 sur courbes Pasta ; tous les PQC réseau/hachage).
- Chronologie CNSA 2.0 : acquisitions 2027, signature logicielle 2030 (LMS/XMSS dès maintenant), navigateurs/serveurs/OS 2033, horizon NSM-10 2035.
- Démo ML-DSA en direct : paire de clés déterministe, signature et vérification de votre message + détection de falsification —— via le port TS pur FIPS-204-final du dépôt, vérifié octet par octet contre des binaires de référence PQClean compilés localement.
- Identifiant de blobs : collez une clé/signature en hex/base64 — la longueur est confrontée à chaque jeu de paramètres.
À savoir : la numérotation FIPS des anciens blogs est souvent décalée ; l'outil ancre le mapping vérifié (ML-DSA = 204, SLH-DSA = 205, FN-DSA = 206 brouillon, ML-KEM = 203). Les preuves BBS ne sont pas de taille fixe : plancher draft-12 = 3 points G1 + 4 scalaires = 272 octets, +32 par scalaire supplémentaire.