Des signatures prêtes pour l’ère quantique.

Pourquoi y penser dès maintenant.

Une signature doit rester vérifiable aussi longtemps que le contrat qu’elle protège.

• Des contrats qui durent : Un bail, un prêt ou un contrat de travail se conserve dix, vingt ou trente ans. Sa signature doit tenir aussi longtemps.
• Une menace connue : Un ordinateur quantique suffisamment puissant pourrait un jour falsifier les signatures RSA et ECDSA utilisées aujourd’hui.
• Un standard publié : Le NIST a publié ML-DSA en 2024 (FIPS 204). Les formats X.509 et CMS l’intègrent déjà (RFC 9881 et 9882).

Trois modes, un seul paramètre.

Choisissez le mode à la création de la demande. Le reste du parcours ne change pas.

Classique · Par défaut

Le parcours actuel, inchangé.

• Dans le PDF : Une signature PAdES RSA ou ECDSA
• Dans le dossier de preuve : Rapport de preuve et evidence.json
• Lisible dans Adobe : Oui
• Résiste aux attaques quantiques connues : Non

Hybride · Recommandé pour tester

Lisible partout aujourd’hui, prouvable demain.

• Dans le PDF : La signature PAdES classique, seule
• Dans le dossier de preuve : En plus : une signature ML-DSA détachée sur exactement les mêmes octets
• Lisible dans Adobe : Oui, pour la partie classique
• Résiste aux attaques quantiques connues : Par la preuve ML-DSA

ML-DSA · Expérimental

Entièrement post-quantique, vérifiable avec Khatm.

• Dans le PDF : Une signature PAdES ML-DSA
• Dans le dossier de preuve : Rapport de preuve et evidence.json
• Lisible dans Adobe : Pas encore
• Résiste aux attaques quantiques connues : Oui

Variantes ML-DSA-44, 65 (par défaut) et 87. Hors sandbox, ml-dsa et hybrid sont refusés (422) et rien n’est créé.

Votre intégration ne change pas.

Ajoutez signature_algorithm à la création. Après signature, chaque demande porte un bloc verification lisible par votre code.

Vérifiable par tout le monde.

Les lecteurs PDF ne savent pas encore valider ML-DSA. La page publique « Vérifier un document » le fait : déposez le PDF et sa preuve, rien n’est conservé.

• Le document n’a pas changé d’un octet
• La signature correspond à son certificat
• Le certificat remonte à une autorité connue
• La preuve ML-DSA porte bien sur ce document
• Un document hybride sans sa preuve n’est jamais déclaré valide

Signatures contre-vérifiées par des outils indépendants : iText 9.5 et OpenSSL 3.6.

Ce que nous ne promettons pas encore.

La cryptographie post-quantique est jeune. Voici, sans détour, où en est l’écosystème.

• Sans valeur juridique : Les signatures ML-DSA de la sandbox reposent sur une PKI de test. Elles ne sont ni qualifiées ni certifiées.
• Lecteurs PDF : Adobe Acrobat et les autres lecteurs ne valident pas encore ML-DSA. Le mode hybride garde une signature lisible partout.
• Horodatage : L’autorité d’horodatage signe encore en RSA : la date n’est pas protégée contre un attaquant quantique.
• Normes en cours : L’ETSI n’a pas encore publié de profil PAdES pour ML-DSA. Khatm suit le PAdES baseline et les RFC 9881 et 9882.
• Module non certifié : La bibliothèque utilisée, Bouncy Castle, n’est pas un module cryptographique validé FIPS 140.

La suite, étape par étape.

Chaque étape lève une limite. Aucune n’est promise à une date précise.

• Clés en HSM : Des clés ML-DSA générées et conservées dans un module matériel.
• Certificats reconnus : Une autorité qui délivre des certificats ML-DSA, avec révocation.
• Horodatage post-quantique : Dès qu’une autorité d’horodatage ML-DSA sera disponible.
• Normes et lecteurs : Les profils ETSI, puis la prise en charge par les lecteurs PDF.

Questions fréquentes.

Mes signatures actuelles sont-elles menacées ?

Pas aujourd’hui : aucun ordinateur quantique connu ne peut falsifier une signature RSA ou ECDSA. Le sujet concerne les documents qui doivent rester vérifiables pendant de nombreuses années.

Puis-je l’utiliser pour de vrais contrats ?

Pas encore. Les signatures ML-DSA de la sandbox reposent sur une PKI de test et n’ont pas de valeur juridique. Pour vos documents réels, gardez le mode classique.

Quel mode choisir pour tester ?

Le mode hybride : le PDF garde une signature classique lisible partout, et la preuve ML-DSA l’accompagne dans le dossier de preuve.

Le signataire voit-il une différence ?

Non. Il reçoit le même e-mail et signe de la même façon. Seul l’algorithme utilisé pour sceller le document change.

Pourquoi les signatures sont-elles plus lourdes ?

Une signature ML-DSA-65 fait environ 3,3 Ko, contre 256 octets pour RSA-2048. Pour un contrat de quelques pages, la différence reste négligeable.

Comment vérifier une signature ML-DSA ?

Sur la page publique « Vérifier un document », ou avec POST /v1/verify. Déposez le PDF et, pour un document hybride, sa preuve .p7s ou son evidence.json.

Testez l’après-quantique sans rien casser.

Le mode classique reste la valeur par défaut. La sandbox post-quantique n’est pas encore ouverte à tous : écrivez-nous pour être prévenu et la tester sur vos propres documents.

contact@khatm.io