Khatm
Experimental · Sandbox
Signatures ready for the quantum era.
Khatm is testing ML-DSA, the signature algorithm standardized by NIST to withstand quantum computers. Same API, same journey for the signer: a single parameter changes.
Test PKI, no legal value. Classic mode remains the default.
Why think about it now.
A signature must stay verifiable for as long as the contract it protects.
- Contracts that last : A lease, a loan or an employment contract is kept for ten, twenty or thirty years. Its signature must hold for as long.
- A known threat : A sufficiently powerful quantum computer could one day forge the RSA and ECDSA signatures used today.
- A published standard : NIST published ML-DSA in 2024 (FIPS 204). The X.509 and CMS formats already include it (RFC 9881 and 9882).
Three modes, one parameter.
Choose the mode when you create the request. The rest of the journey does not change.
Classic · Default
Today’s journey, unchanged.
- In the PDF : An RSA or ECDSA PAdES signature
- In the evidence package : Evidence report and evidence.json
- Readable in Adobe : Yes
- Withstands known quantum attacks : No
Hybrid · Recommended for testing
Readable everywhere today, provable tomorrow.
- In the PDF : The classic PAdES signature, alone
- In the evidence package : Plus: a detached ML-DSA signature over exactly the same bytes
- Readable in Adobe : Yes, for the classic part
- Withstands known quantum attacks : Through the ML-DSA proof
ML-DSA · Experimental
Fully post-quantum, verifiable with Khatm.
- In the PDF : An ML-DSA PAdES signature
- In the evidence package : Evidence report and evidence.json
- Readable in Adobe : Not yet
- Withstands known quantum attacks : Yes
ML-DSA-44, 65 (default) and 87 variants. Outside the sandbox, ml-dsa and hybrid are refused (422) and nothing is created.
Your integration stays the same.
Add signature_algorithm when you create the request. Once signed, each request carries a verification block your code can read.
Verifiable by anyone.
PDF readers cannot validate ML-DSA yet. The public “Verify a document” page does: drop the PDF and its proof, nothing is kept.
- The document has not changed by a single byte
- The signature matches its certificate
- The certificate chains to a known authority
- The ML-DSA proof covers this very document
- A hybrid document without its proof is never reported valid
Signatures cross-checked with independent tools: iText 9.5 and OpenSSL 3.6.
What we don’t promise yet.
Post-quantum cryptography is young. Here, plainly, is where the ecosystem stands.
- No legal value : Sandbox ML-DSA signatures rely on a test PKI. They are neither qualified nor certified.
- PDF readers : Adobe Acrobat and other readers do not validate ML-DSA yet. Hybrid mode keeps a signature readable everywhere.
- Timestamps : The timestamp authority still signs with RSA: the date is not protected against a quantum attacker.
- Standards in progress : ETSI has not yet published a PAdES profile for ML-DSA. Khatm follows PAdES baseline and RFC 9881 and 9882.
- Uncertified module : The library used, Bouncy Castle, is not a FIPS 140 validated cryptographic module.
What comes next, step by step.
Each step lifts a limit. None is promised for a specific date.
- Keys in an HSM : ML-DSA keys generated and kept in a hardware module.
- Recognized certificates : An authority that issues ML-DSA certificates, with revocation.
- Post-quantum timestamps : As soon as an ML-DSA timestamp authority is available.
- Standards and readers : ETSI profiles, then support in PDF readers.
Frequently asked questions.
Are my current signatures at risk?
Not today: no known quantum computer can forge an RSA or ECDSA signature. The concern is for documents that must stay verifiable for many years.
Can I use it for real contracts?
Not yet. Sandbox ML-DSA signatures rely on a test PKI and have no legal value. For your real documents, keep classic mode.
Which mode should I test?
Hybrid mode: the PDF keeps a classic signature readable everywhere, and the ML-DSA proof comes with it in the evidence package.
Does the signer see any difference?
No. They receive the same email and sign the same way. Only the algorithm that seals the document changes.
Why are the signatures larger?
An ML-DSA-65 signature is about 3.3 KB, versus 256 bytes for RSA-2048. For a contract of a few pages, the difference is negligible.
How do I verify an ML-DSA signature?
On the public “Verify a document” page, or with POST /v1/verify. Drop the PDF and, for a hybrid document, its .p7s proof or its evidence.json.
Try post-quantum without breaking anything.
Classic mode remains the default. The post-quantum sandbox is not open to everyone yet: write to us to be notified and try it on your own documents.
contact@khatm.io