Post-Quantum Security

Research data outlives its cryptography. A genome deposited today is still sensitive in thirty years - long past the point where a cryptographically relevant quantum computer is expected to break the elliptic-curve schemes that protect most of the web. Ekayana is built so that the data you store now stays protected then.

The threat model: harvest now, decrypt later

An adversary does not need a quantum computer today to benefit from one tomorrow. They need only to record traffic and ciphertext now and decrypt it once the hardware exists. Any system whose confidentiality rests on RSA or elliptic curves is, for long-lived data, already leaking on a delay.

This drives three design rules:

Confidentiality must be post-quantum today - encryption at rest cannot wait for a migration deadline.
Authorization must be post-quantum today - a forged capability is permanent damage, and signatures over long-lived grants must resist future forgery.
Standards, not experiments - the algorithms must be the NIST-standardized ones, from a validated implementation.

The algorithms

Ekayana uses the NIST post-quantum standards exclusively, via aws-lc-rs (AWS-LC, which offers a FIPS-validated cryptographic module).

Purpose	Algorithm	Standard	Parameters
Signatures	ML-DSA-87	FIPS 204	2592-byte public key, 4627-byte signature
Key encapsulation	ML-KEM-1024	FIPS 203	1568-byte encapsulation key, 1568-byte ciphertext
Symmetric	AES-256-GCM	FIPS 197 / SP 800-38D	256-bit keys, AEAD
Derivation	HKDF-SHA256	RFC 5869	domain-separated

ML-DSA-87 and ML-KEM-1024 are the highest parameter sets in their standards (NIST security category 5), chosen deliberately: the payload cost is measured in kilobytes, while the data being protected has a multi-decade lifetime.

Not legacy Dilithium. ML-DSA-87 is the final FIPS 204 standard. It is not interoperable with pre-standard round-3 CRYSTALS-Dilithium5 implementations, which the platform no longer uses anywhere.

Where each algorithm applies

┌────────────────────────────────────────────────────────────────┐
│  Identity        did:bio DIDs + ML-DSA-87 verification methods │
├────────────────────────────────────────────────────────────────┤
│  Session auth    ML-DSA-87 signed tokens (public-key verified) │
├────────────────────────────────────────────────────────────────┤
│  Authorization   ML-DSA-87 signed UCAN capability tokens       │
├────────────────────────────────────────────────────────────────┤
│  Storage         ML-KEM-1024 -> HKDF -> AES-256-GCM at rest    │
└────────────────────────────────────────────────────────────────┘

1. Identity

The did:bio method treats ML-DSA-87 as a first-class verification method type. A DID document can carry a post-quantum assertion key alongside its classical keys:

json

{
  "id": "did:bio:devnet:2T6zLF…#pq",
  "type": "JsonWebKey",
  "controller": "did:bio:devnet:2T6zLF…",
  "publicKeyJwk": {
    "kty": "AKP",
    "alg": "ML-DSA-87",
    "pub": "<base64url - 2592 bytes>"
  }
}

On-chain control remains Ed25519 for as long as the underlying ledger signs transactions that way - a documented residual risk. Off-chain assertions, however, are post-quantum immediately.

2. Session authentication

Auth tokens are a JWS-shaped structure signed with ML-DSA-87:

base64url(header) . base64url(claims) . base64url(ML-DSA-87 signature)

The complete signature travels in the token and is verified against the service public key. Verification requires no secret material, so read-only replicas and independent auditors can validate tokens without the ability to mint them.

3. Authorization

Capability tokens place every trusted field - issuer, audience, expiry, and the capability list - inside the signed payload. Editing a capability invalidates the signature. See UCAN Authorization for the full validation pipeline.

4. Storage

Payloads are sealed before they ever reach IPFS:

fresh 32-byte content key
   ├── AES-256-GCM --> sealed payload
   └── ML-KEM-1024 encapsulation
         └── HKDF-SHA256 -> AES-256-GCM -> sealed content key

The CID therefore addresses ciphertext. Anyone who retrieves the blob - including any IPFS node replicating it - holds bytes that are useless without the ML-KEM decapsulation key. See Privacy Controls.

Key management

The platform derives its entire signing identity from a single 32-byte seed, so deployments hold two secrets:

Variable	Contents	Used for
`MLDSA_SEED`	base64, 32 bytes	Derives the ML-DSA-87 service identity
`MLKEM_SECRET_KEY`	base64	ML-KEM-1024 decapsulation key

bash

# Generates both, and prints the resulting service DID
cargo run -- generate-keys --output ./keys

Because the signing key is derived from the seed rather than stored, every replica configured with the same seed reproduces the identical issuer DID - horizontal scaling requires no key distribution protocol.

Operational note. Both values are secrets. The seed reconstructs the signing key; the ML-KEM key decrypts every payload sealed to it. Store them in a secret manager, never in source control, and rotate by re-issuing tokens after a seed change.

Open-source components

The post-quantum work is factored into reusable crates rather than locked inside the platform:

Component	What it provides
`did-bio-core`	The `did:bio` data model and resolution algorithm, with ML-DSA-87 verification methods
`varsig` (ML-DSA extension)	ML-DSA-44/65/87 signature suites for UCAN envelopes
`pq-space`	Mixed classical/post-quantum UCAN principals and ML-KEM content-key wrapping

What is not post-quantum

Stating the boundary honestly matters more than a clean marketing claim:

Transport security is TLS as offered by the platform's edge; hybrid post-quantum key exchange depends on the deployment's TLS terminator.
On-chain transaction signatures remain Ed25519, inherited from the underlying ledger.
Content addressing uses SHA-256, which is not threatened by quantum attacks in any practical sense (Grover's algorithm only halves the effective preimage strength, leaving 128 bits).

Resources

UCAN Authorization Dedicated Gateways