Post Quantum Cryptography: Securing Research Data for the Next Century

The Quantum Threat to Research Data

Quantum computers capable of breaking current cryptographic standards are no longer science fiction. Google, Microsoft and others have demonstrated error corrected logical qubits. A 2024 demonstration entangled 24 of them, far below the roughly 2,330 that breaking a 256 bit elliptic curve is estimated to need. Nobody can date the crossing, and that uncertainty is itself the argument for moving first.

For research data, this presents an existential threat:

• An adversary can store encrypted data today and decrypt it when quantum computers mature.
• Research data often needs protection for decades.
• Medical, genetic, and national security research requires the highest protection.

NIST Post Quantum Standards

In 2024, NIST finalized the first post quantum cryptographic standards after an 8 year evaluation process:

ML-KEM, formerly CRYSTALS-Kyber, for key encapsulation

• Its security rests on Module Learning With Errors.
• Public keys run from 800 to 1568 bytes, against 32 bytes for X25519.
• It is about as fast as X25519. Measured with aws-lc-rs on an Apple M4 Pro, a full ML-KEM-768 exchange takes about 23 microseconds against about 34 for X25519. The cost is size rather than time.

ML-DSA, formerly CRYSTALS-Dilithium, for digital signatures

• Its security rests on Module Learning With Errors and a variant of Module-SIS.
• Signatures run from 2420 to 4627 bytes, against 64 bytes for Ed25519.
• Security levels 2, 3 and 5 correspond to 128, 192 and 256 bit equivalents.

SLH-DSA, formerly SPHINCS+, for stateless hash based signatures

• Its security rests on hash functions alone, which is the most conservative basis.
• Signatures run from 7856 to 49856 bytes.
• It suits long term archival signatures.

ML-DSA-87 in Bio-DID-Seq

Bio-DID-Seq uses ML-DSA-87, the final FIPS 204 standard at its highest parameter set, NIST security category 5, where a long lived assertion needs it, and it is specific about where it does not.

• A did:bio document can carry an ML-DSA-87 assertion method. The key is 2592 bytes, larger than a Solana transaction, so it is uploaded through a key buffer.
• pq-ucan accepts ML-DSA principals in a delegation chain next to Ed25519.
• The service's own did:bio carries an ML-DSA-87 assertion key once it is registered, though nothing signs with that key yet.
• Wallet sign in, browser session keys, capability tokens and on-chain control are Ed25519, because the wallets that sign them are Solana wallets.

The part that is post quantum in daily use is storage. The content key of every upload is wrapped with ML-KEM-1024.

ML-DSA-87 derives from CRYSTALS-Dilithium5, and the two are often used interchangeably. They are not interoperable. The standardized ML-DSA-87 differs from the prestandard round 3 Dilithium5 implementations, and Bio-DID-Seq uses the standardized algorithm exclusively.

Implementation Example

The platform's own crates do this in Rust. did-bio-core builds the document's verification method and checks a signature against it.

use aws_lc_rs::signature::{KeyPair, PqdsaKeyPair, ML_DSA_87_SIGNING};
use did_bio_core::verify::verify_with_method;
use did_bio_core::{BioDid, VerificationMethodMap};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let did: BioDid = "did:bio:devnet:2T6zLFvMx7NJac5qQtiKTaPhMwHLkwKETWjUK1yKv4tc".parse()?;

    // An ML-DSA-87 keypair from aws-lc-rs, the library the platform uses.
    let pq = PqdsaKeyPair::generate(&ML_DSA_87_SIGNING)?;
    let method = VerificationMethodMap::ml_dsa_87(did.url("pq"), did.to_string(), pq.public_key().as_ref())?;

    let claim = br#"{"dataset":"bafy...","statement":"collected under IRB 2026-114"}"#;
    let mut signature = vec![0u8; 4627];
    let len = pq.sign(claim, &mut signature)?;
    signature.truncate(len);

    verify_with_method(&method, claim, &signature)?;
    println!("Signature size: {} bytes", signature.len()); // 4627
    Ok(())
}

The key reaches a DID document with bio-did-resolver add-key pq --type ml-dsa-87 --key-file pq.pub --flags assertion, which uploads it in five transactions. A verifier then finds it under assertionMethod and checks it with verify_for_relationship.

Hybrid Cryptography: Belt and Suspenders

During the transition, the safest signature is a hybrid, two signatures over the same bytes, one classical and one post quantum, which must both verify. Bio-DID-Seq does not produce hybrid signatures. A did:bio document can hold an Ed25519 and an ML-DSA-87 assertion method side by side, so an application that wants a hybrid can sign with both and require both to verify against the document.

This approach gives three things.

• Ed25519 protects against today's threats.
• ML-DSA-87 protects against quantum attacks.
• If either algorithm is compromised, the other still provides protection.

Performance Considerations

Post quantum cryptography has larger keys and signatures, and the cost is bandwidth rather than time. These are means measured with aws-lc-rs on an Apple M4 Pro.

For research data operations (typically measured in seconds), this overhead is negligible.

Migration Strategy

Phase 1: Inventory (Now)

• Identify all cryptographic dependencies
• Catalog data requiring long term protection
• Assess quantum risk timeline

Phase 2: Hybrid Deployment (2025-2027)

• Deploy hybrid signatures for new data
• Maintain backward compatibility
• Monitor NIST guidance updates

Phase 3: Post Quantum Primary (2028+)

• Transition to PQ only for new systems
• Sign legacy data again with PQ algorithms
• Deprecate classical only signatures

What actually forces the decision

The reason to move now has nothing to do with when a cryptographically relevant quantum computer arrives, and arguing about that date is a way of avoiding the question.

It is that "harvest now, decrypt later" already works. An adversary can record encrypted traffic today and hold it, and any confidentiality that has to survive into the 2040s is being decided by the algorithm you choose in 2026. Genomic data is the uncomfortable case. It identifies relatives who never consented, and it does not stop being sensitive.

Signatures sit differently, and it is worth separating them. A signature only needs to resist forgery while it is still being relied upon, so a signing key rotated on a normal schedule is a smaller exposure than a ciphertext archived for thirty years. The migration order follows from that, long lived confidentiality first, long lived signatures second, session scoped anything last.

None of this makes the transition urgent in the sense of dropping other work. It makes it ordered, and the ordering is the part most migration plans get backwards.

References: NIST PQC Standards, FIPS 204, ML-DSA, Quantum Computing Report