Documentation

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, and it is specific about where that promise holds and where it does not.

The threat model

The threat is known as harvest now, decrypt later. An adversary does not need a quantum computer today to benefit from one tomorrow. They need only to record 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.
Long lived assertions must be post quantum today. A key that vouches for a dataset's provenance has to resist forgery for as long as the dataset is cited.
Standards rather than experiments. The algorithms are the NIST standards, from a validated implementation.

The algorithms

Everything post quantum comes from aws-lc-rs, which offers a FIPS validated 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. The cost is kilobytes per key, while the data being protected has a lifetime of decades.

ML-DSA-87 is the final FIPS 204 standard. It is not interoperable with prestandard round 3 CRYSTALS-Dilithium5 implementations. The registry's on-chain type tag still reads Dilithium5 for historical reasons, and the bytes it stores are ML-DSA-87.

Where each algorithm applies

Where each post quantum algorithm applies, and where none does. ML-DSA-87 assertion keys in DID documents, ML-DSA principals in pq-ucan, ML-KEM-1024 wrapped content keys, and Ed25519 for on-chain control.

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>"
  }
}

The JWK mapping follows draft-ietf-cose-dilithium and is provisional until the IETF registration is final. Because 2592 bytes exceed a Solana transaction, the key is uploaded in three chunks through a staging account and folded into the document in a fifth transaction. The resolver command line does this behind a single add-key call. The registry program page describes the mechanism, and did-bio-core verifies signatures under such a key with its verify feature. ML-DSA-87 only signs, so the registry refuses keyAgreement on such a method.

On-chain control remains Ed25519 for as long as the ledger signs transactions that way. Off-chain assertions can be post quantum now, though the platform itself signs nothing with an ML-DSA-87 key yet.

2. Authorization

pq-ucan accepts ML-DSA-44, 65 and 87 principals in a UCAN chain as ordinary algorithms, next to Ed25519, P-256 and secp256k1. A did:bio researcher can delegate to an ML-DSA-87 device key and the validator checks the chain without knowing which hop is post quantum. See UCAN Authorization.

What the platform signs with in practice is Ed25519, because delegations are signed by wallets and wallets sign Ed25519. The post quantum path exists for service and device keys that need it, and it is the same code.

3. Storage

Payloads are sealed before they reach IPFS.

Envelope encryption. A fresh 32 byte content key per payload seals the payload with AES-256-GCM before it goes to IPFS, and is itself sealed by ML-KEM-1024 encapsulation through HKDF-SHA256 into AES-256-GCM.

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. The same wrap, from pq-space, can carry a content key inside a UCAN delegation. The platform's own shares do not use that yet, because the service opens a shared file with its own key. See Privacy Controls.

Key management

The service derives its whole identity from a single 32 byte seed, so a deployment holds two secrets.

Variable	Contents	Used for
`SERVICE_SEED`	base64, 32 bytes	Derives, under distinct HKDF labels, an Ed25519 subject key and an ML-DSA-87 assertion key. The service's `did:bio` is the subject key on the configured network
`MLKEM_SECRET_KEY`	base64	The ML-KEM-1024 decapsulation key that opens content keys

Every replica configured with the same seed names the same did:bio, so horizontal scaling needs no key distribution protocol. The service DID is the executor every invocation is addressed to. It signs no tokens and holds no user key. Registering it on the registry publishes the ML-DSA-87 key as an assertion method. The service-identity command exports the keypair and the raw key and prints the two bio-did-resolver commands that do it.

Both values are secrets. The seed reconstructs the service's keys, and the ML-KEM key decrypts every payload sealed to it. Store them in a secret manager, never in source control. A seed change renames the service. Invocations addressed to the old DID stop validating, and nothing else is affected, since the service issued nothing.

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, ML-DSA-87 verification methods and signature verification
`bio-did-registry`	The Solana program, with the key buffer that gets a 2.5 KB key on-chain, also usable as a client library
`bio-did-resolver`	Command line resolver and registry client, including the chunked upload of ML-DSA-87 keys
`pq-ucan`	UCAN 1.0 with ML-DSA-44/65/87 principals and provisional varsig headers
`pq-space`	`did:bio` principals for pq-ucan and ML-KEM-1024 content key wrapping carried in the delegation

What is not post quantum

The boundary is as follows.

On-chain transaction signatures remain Ed25519, inherited from the ledger.
Wallet signed tokens are Ed25519, because that is what wallets sign with today. The chain validator would accept an ML-DSA issuer without change.
Session tokens are opaque random bearer values rather than signatures. Their security is that of the TLS channel and the hash they are stored under.
Transport security is TLS as offered by the platform's edge. Hybrid post quantum key exchange depends on the deployment's TLS terminator.
Content addressing uses SHA-256, which quantum attacks do not threaten in any practical sense. Grover's algorithm halves the effective preimage strength, leaving 128 bits.