Post-Quantum Cryptographic Capabilities

00 Two different jobs

Signatures prove. Key establishment protects.

A digital signature proves who issued something and that it has not changed since. That is what a receipt needs, so R-Series receipts are signed.

A key-encapsulation mechanism (KEM) does something else: it lets two parties agree a secret key so that data can be encrypted in transit or at rest. A KEM never signs anything and cannot make a receipt trustworthy on its own.

So the families below sit in two groups. The signature families matter for evidence; the KEM protects what travels between systems and what is stored.

01 Digital signatures

ML-DSA and SLH-DSA.

FIPS 204 · LATTICE-BASED

ML-DSA

What it does: Signs and verifies. It is the general-purpose post-quantum signature in the NIST standards.
Trade-offs: Signing and verification are fast. Keys and signatures are much larger than Ed25519, so R-Series signs a compact receipt that holds hashes of the content, not the content itself.
Variants implemented: ML-DSA-44, ML-DSA-65, ML-DSA-87.
Where it sits in R-Series: ML-DSA-65 is the post-quantum signature in every R-Series receipt, alongside the classical Ed25519 signature. ML-DSA-87 is implemented and tested but not yet in a receipt suite. ML-DSA-44 is accepted for verification only.

ImplementationImplemented and tested
R-Series integrationML-DSA-65: in the receipt suite, running in staging
Product availabilityStaging only (Ed25519 + ML-DSA-65 receipts); other sets not available yet

FIPS 205 · HASH-BASED

SLH-DSA

What it does: Signs and verifies, based on SPHINCS+. Its security rests only on hash functions, a conservative assumption suited to records that must hold for decades.
Trade-offs: Signatures are considerably larger than ML-DSA and signing is much slower. The sets we implement are the small-signature (“s”) variants, which accept slower signing for smaller output.
Variants implemented: SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, SLH-DSA-SHA2-192s.
Where it sits in R-Series: SLH-DSA-SHA2-192s is being integrated for long-horizon checkpoints, in development. It is not a receipt suite. The two 128s sets are implemented and tested, with no R-Series integration yet.

ImplementationImplemented and tested
R-Series integrationSHA2-192s: in development (long-horizon checkpoints); 128s sets: not integrated
Product availabilityNot available yet

02 Key establishment

ML-KEM.

FIPS 203 · LATTICE-BASED

ML-KEM

What it does: Establishes a shared secret key between two parties (key generation, encapsulation, decapsulation). It does not sign.
Trade-offs: Fast, with public keys and ciphertexts larger than classical elliptic-curve key exchange.
Variants implemented: ML-KEM-512, ML-KEM-768, ML-KEM-1024.
Where it sits in R-Series: ML-KEM-768 is used for encrypted envelopes, in development. ML-KEM-512 is decrypt-only. ML-KEM-1024 is implemented and tested.

ImplementationImplemented and tested
R-Series integrationIntegrated in development (encrypted envelopes)
Product availabilityNot available yet

IETF DRAFT · HYBRID KEM

X-Wing, next to ML-KEM

What it is: A hybrid KEM (ML-KEM-768 + X25519) from an IETF draft. It is not a standard. It combines the post-quantum and the classical key exchange, so an attacker has to break both.
Where it sits in R-Series: The preferred choice for encrypted envelopes, in development.

ImplementationImplemented and tested
R-Series integrationIn development
Product availabilityNot available yet

Other families are under evaluation and appear here only once they are implemented and tested.

03 Parameter sets

Exactly what is implemented.

Each table lists only the sets that are implemented and tested. A set that is not listed is not supported.

ML-DSA (FIPS 204): 3 sets

Set	Status
ML-DSA-44	Implemented and tested; accepted for verification only.
ML-DSA-65	Implemented and tested; the post-quantum signature in R-Series receipts (Ed25519 + ML-DSA-65), running in staging.
ML-DSA-87	Implemented and tested; not yet in a receipt suite.

SLH-DSA (FIPS 205, based on SPHINCS+): 3 sets

Set	Status
SLH-DSA-SHA2-128s	Implemented and tested.
SLH-DSA-SHAKE-128s	Implemented and tested.
SLH-DSA-SHA2-192s	Implemented and tested; for long-horizon checkpoints, in development.

ML-KEM (FIPS 203): 3 sets, plus X-Wing

Set	Status
ML-KEM-512	Implemented and tested; decrypt-only.
ML-KEM-768	Implemented and tested; used for encrypted envelopes in development.
ML-KEM-1024	Implemented and tested.
X-Wing	Hybrid KEM (ML-KEM-768 + X25519; IETF draft, not a standard): implemented and tested, in development.

Classical partners

Algorithm	Status
Ed25519	RFC 8032: the classical signature in R-Series receipts, alongside ML-DSA-65.
X25519	RFC 7748: classical component of the X-Wing hybrid.

04 Standards and validation

Tested against vectors. Not formally validated.

The standards: ML-KEM: FIPS 203. ML-DSA: FIPS 204. SLH-DSA: FIPS 205, based on SPHINCS+. Each implementation follows the final published standard, not an earlier competition submission.

Our implementations are checked against published test vectors, including NIST ACVP vectors and other public corpora of known answers and malformed inputs, and cross-checked against an independent implementation. That is testing, not formal validation. No formal validation certificate is claimed for any of them.

How each standard is used in a receipt, and what R-Series adds on top, is on the standards page.

05 Reading this page correctly

What this does not mean.

Not every receipt uses every family.

Receipts are signed with Ed25519 + ML-DSA-65, and both signatures must check. SLH-DSA and ML-KEM are not part of a receipt signature.

KEMs do not sign.

ML-KEM and X-Wing protect data in transit and at rest. They add nothing to the proof a receipt carries.

SLH-DSA is not a receipt suite.

Its use for checkpoints and long-horizon records is in development.

No ML-DSA-87 receipts yet.

An ML-DSA-87 receipt profile is reserved and not available yet. ML-DSA-87 itself is implemented and tested.

Several algorithms are not agility.

Having more than one algorithm is not by itself crypto-agility, a migration path or protection against downgrade. Those need their own rules and evidence.

Staging is not production.

R-Series is in development. Only the Ed25519 + ML-DSA-65 receipt suite runs, and only on staging.

06 Questions

What people ask us.

Which algorithms sign an R-Series receipt?

Ed25519 and ML-DSA-65, together. A verifier rejects the receipt if either signature is missing or fails.

Can I try it?

Yes. The browser demo signs with Ed25519 + ML-DSA-65 and checks both legs on your device. It runs no other algorithm.

Where do I find suite identifiers and encodings?

On the developers page, under algorithms and profiles.

Why does R-Series not use post-quantum signatures alone?

Post-quantum implementations are newer. The hybrid keeps the classical guarantee while adding the post-quantum one. The wider reasoning is on the post-quantum page.

Need a specific algorithm or parameter set for your programme? Talk to us.