Post-Quantum Cryptography (PQC) support in iText

As quantum computers progress from theory to reality, they introduce the threat of Q‑Day: the point at which a quantum machine could potentially break existing encryption instantly.

However, quantum-resistant algorithms have been developed to counter such risks. In this article we cover iText’s work to implement support for the upcoming PDF standards for post-quantum digital signatures.

Why should PDF developers care about Post-Quantum Cryptography (PQC)?

Although large-scale quantum computers might still be years or even decades away, their potential to break today’s most common encryption and digital signature algorithms is a real concern for industries built on long-term digital trust. For the PDF world, where a signed document might need to remain valid for decades, this is a significant problem to be solved.

Today's PDF digital signatures rely on RSA and ECC (Elliptic Curve Cryptography) algorithms. A sufficiently powerful quantum computer could break these, undermining the authenticity and integrity of billions of signed documents. The “harvest now, decrypt later” threat where adversaries store encrypted data to decrypt later applies to signatures too.

That’s why we are already exploring how to make PDF documents quantum-resistant.

Quantum-resistant digital signatures

Thankfully, the risks posed by Q‑Day have been on experts’ radar for some time, leading to the development of encryption algorithms specifically designed to survive quantum‑based attacks.

NIST released the principal three PQC standards including standards for algorithms can be used to generate and verify digital signatures: ML-DSA and SLH-DSA.

Following NIST's standardization of PQC algorithms, the PDF Association has been driving formal adoption. A key milestone was the agreement at PDF Days 2025 to integrate these algorithms into the PDF specification. This means that official support in the PDF specification will be coming soon and so it's time for us to implement support in iText.

By building on the robust Bouncy Castle cryptographic modules, iText now includes proof‑of‑concept capabilities for generating and validating post‑quantum digital signatures in PDFs using Bouncy Castle’s supported algorithms. These include not only the standardized ML-DSA and SLH-DSA, but also some experimental algorithms (LMS, XMSS) and algorithms that have been part of the NIST PQC competition, but have not been standardized yet (such as Falcon – to be standardized as FN-DSA, Picnic, and Rainbow).

Support by iText: current status

What works right now (for iText Core 9.5.0+):

Using Bouncy Castle, iText can generate quantum-resistant digital signatures within a PDF document (for experimental algorithms Bouncy Castle PQC provider could be required).
Our library can also validate these signatures, completing the full lifecycle within an iText-powered workflow.
This lets you experiment, develop, and prepare your applications for the upcoming standard.

This is a pre-standard implementation. The official PDF specification (ISO 32000) does not yet define how to embed and interpret PQC signatures. Therefore:

A PDF signed with our current PQC implementation is not a valid, standards-compliant PDF for this specific feature.
Other PDF processors (Adobe Reader, browser plugins, etc.) will not be able to validate these signatures, so they are for iText-to-iText workflows only at this stage. But PQC support should be added in the future.
We are actively participating in the PDF Association's technical discussions to ensure our implementation aligns with the emerging standard, so we'll be ready to switch to the official method once it's published.
These are not yet supported in BC-FIPS mode, as the official support for PQC-safe algorithms for Bouncy Castle FIPS are still to be released: see https://www.bouncycastle.org/download/bouncy-castle-java-fips/roadmap/ (2.2.0 is currently under test) and https://www.bouncycastle.org/download/bouncy-castle-c-fips/roadmap/ (2.0.0 with scheduled updates). Once PQC-safe BC-FIPS mode is possible, you can be sure iText will be at the forefront of PDF implementations.

Why experiment now? Getting ahead of the curve

If it's not standard yet, why bother?

Future-Proofing your code: understanding the API patterns and handling larger signature sizes (a known trait of PQC algorithms) now will smooth your transition later.
Building institutional knowledge: develop internal expertise on PQC workflows, key management, and performance implications.
Industry leadership: be ready to offer quantum-safe signing options to security-conscious clients the moment the standard is approved.

The transition to post-quantum cryptography requires changes across the entire stack: from hardware security modules and Certificate Authorities to viewers and validation tools. By starting the engine now, iText ensures that developers who choose our library will be at the forefront of securing digital documents for the quantum era.

We’re committed to turning this PoC into robust, standards-compliant support as soon as the PDF specification is ready. The quantum threat is on the horizon, and with iText, you’re building on a foundation that’s looking ahead.

Code samples

Code samples are available on GitHub:

Java

.NET

Differences between PQC digital signature algorithms

The NIST Post-Quantum Cryptography standardization process has evaluated dozens of candidates. It’s crucial to understand the landscape, as the chosen algorithm and set of parameters affect signature size, signing performance, security level, and so on. Below is a high-level comparison.

Algorithm (Common Name)	NIST Status	Type / Security Basis	Key & Signature Size	Notes & Best For
ML-DSA (CRYSTALS-Dilithium)	Standardized (FIPS 204) https://csrc.nist.gov/pubs/fips/204/final	Modular Lattice-based	Moderate (~2-4 KB)	Primary general-purpose standard. Excellent balance of security, speed, and size. The main recommended algorithm for most new implementations.
SLH-DSA (SPHINCS+)	Standardized (FIPS 205) https://csrc.nist.gov/pubs/fips/205/final	Stateless Hash-based	Very Large (~8-50 KB)	Conservative "backup" standard. Security relies only on hash functions. Use if concerns arise about the security of lattice math.
FN-DSA (Falcon)	Will be standardized soon (FIPS 206) https://falcon-sign.info/	NTRU Lattice-based	Very Small (~1-1.5 KB)	Where very small signature size is critical. More complex implementation (requires floating-point).
Picnic	Round 3 Alternate	Zero-Knowledge Proofs (MPC)	Large	Interesting security approach, but large signatures and slower performance limited widespread adoption.
Rainbow	Broken (Round 3)	Multivariate Quadratic Equations	Very Small	Cryptanalysis broken after Round 3. Not secure and should not be used.
LMS / XMSS	NIST SP 800-208 (Stateful)	Stateful Hash-based	Small to Moderate	Already used in some niches (e.g., firmware signing). Statefulness (one-time private key per signature) makes key management complex for general document signing.

For most developers beginning their PQC journey, ML-DSA is the recommended starting point. It offers the best practical balance of performance, signature size, and confidence from the extensive NIST evaluation process. Its moderate signature size is more manageable for PDF integration than the very large SLH-DSA signatures, while its security assumptions are widely trusted. When both small size and performance are needed, FN-DSA (Falcon) is the next candidate to evaluate, though its implementation is more delicate.