This morning two research papers dropped that I’ve been thinking about all day. The short version: the timeline for quantum computers cracking elliptic curve cryptography just got significantly shorter, and I’m not going to wait until it’s a fleet problem to deal with it.

So I spent this afternoon shipping post-quantum cryptography across the OpenCastor stack. Here’s what changed, and why.

What the papers say

Google Quantum AI published an optimized Shor’s algorithm targeting secp256k1 — the elliptic curve used by Bitcoin, Ethereum, and a huge swath of modern public-key infrastructure. Their implementation runs on roughly 1,200 logical qubits. On a fast superconducting quantum computer, it recovers a private key from an exposed public key in single-digit minutes.

To put that in physical terms: ~500K physical qubits with today’s surface code error correction. Google demonstrated 105-qubit surface code operation last year. The gap is real, but it’s not infinite.

Oratomic, a stealthy startup with ex-Google Quantum AI and Caltech faculty, took Google’s logical circuit and optimized it for neutral atom architectures. Their estimate: 26,000 physical qubits to break 256-bit ECDSA — roughly a 40x improvement over prior state of the art. The trade-off is speed; neutral atoms run ~1,000x slower, so a single key crack takes about 10 days rather than minutes.

The author’s honest take on timelines: at least a 10% chance of a cryptographically-relevant quantum computer (CRQC) capable of cracking secp256k1 by 2032. Before 2030 still feels unlikely, but no longer dismissible.

One detail that stuck with me: the Google paper uses a zero-knowledge proof to demonstrate the algorithm’s existence without publishing the actual optimizations. Assume the published results are a lower bound. State-of-the-art is being held back.

Why robot identity specifically

Most of the post-quantum conversation focuses on TLS, Bitcoin, and certificate infrastructure. Those are real problems. But there’s a quieter issue that affects robotics specifically: device identity.

Every OpenCastor robot has an identity — a public key that anchors trust for RCAN-signed messages, firmware attestation, and the /.well-known/rcan-node.json manifest. If that key is ECDSA-based, a future adversary with a CRQC can:

1. Impersonate any registered robot
2. Forge firmware attestations
3. Inject into RCAN message streams by spoofing a trusted M2M peer

These aren’t theoretical. Robot fleets that exist today will still be operating in 2032. The firmware they attest to today might be verified in a world where those signatures are no longer trustworthy.

The “harvest now, decrypt later” attack is even simpler: store any signed robot communications today, verify the identities retroactively in 2032 with a CRQC. No live attack needed.

What I shipped today

I have two robots: Bob (RRN-000000000001) and Alex (RRN-000000000005), both mine. Before the fleet grows to include anyone else’s hardware, I wanted quantum-resistant identity baked in from the start. Retrofitting 100 robots is a different problem than migrating 2.

The pqc-hybrid-v1 profile

The new cryptographic profile is called pqc-hybrid-v1: Ed25519 (classical) paired with ML-DSA-65 (NIST FIPS 204, formerly CRYSTALS-Dilithium3). Both signatures are required — a verifier must check both, and both must pass.

The hybrid approach gives us:

• Quantum resistance from ML-DSA-65
• Classical trust continuity from Ed25519 (existing infrastructure still works)
• Explicit migration signal — when everything has moved to PQC verifiers, we drop the Ed25519 half and ship pqc-v1

Signature format: pqc-hybrid-v1.<ed25519_b64url>.<ml_dsa_b64url>

Key sizes to be aware of: ML-DSA-65 public keys are 1,952 bytes (vs 32 bytes for Ed25519). Signatures are 3,309 bytes. This matters for anything with tight size budgets — RCAN envelopes, QR codes, NFC payloads. Worth knowing going in.

What landed

rcan-spec #189 — The cryptographic profile is now formally specified in the RCAN spec as §1.6.4, versioned as v2.3. Includes conformance test cases requiring both signature halves, and the updated /.well-known/rcan-node.json schema with crypto_profile, pqc_public_key, and ed25519_public_key fields.

rcan-py #48 — New rcan/crypto.py with MlDsaKeyPair, HybridSignature, and the full sign/verify primitive set. RobotURI gets explicit sign_pqc()/verify_sig_pqc() methods. M2M signing gets sign_m2m_pqc()/verify_m2m_pqc(). 723 tests passing across Python 3.10/3.11/3.12.

rcan-ts #41 — Same primitives in TypeScript via @noble/post-quantum (pure JS, no WASM, browser + Node compatible). 579 tests passing.

OpenCastor #809 — Robot identity migrated to pqc-hybrid-v1 at the registration layer. On first boot, OpenCastor generates a full hybrid keypair stored at ~/.opencastor/robot_identity.json. The private key never leaves the device. GET /.well-known/rcan-node.json now serves the PQC public keys. The auth layer has explicit deprecation markers on any RS256/ES256 JWT paths.

Fleet expansion gate

Until these PRs merge: no new robot registrations. New robots joining OpenCastor from this point forward will get PQC identity keys from day one, not as a migration.

What’s not solved yet

To be clear about what this doesn’t address:

TLS: The Pi-to-Firebase connection still uses ECDHE-based TLS 1.3. Post-quantum TLS (RFC 8446 + CRYSTALS-Kyber hybrid) is coming to major cloud providers but isn’t GA for Firebase yet. This is on the radar, not in this PR.

JWT signing: The OAuth and provider auth flows still use RS256 or ES256. These are flagged as deprecated in the code but not yet migrated. The spec work is done; the JWT library migration is next.

Key rotation: There’s a procedure for migrating Bob and Alex to the new key format, but it’s a manual process. Automated key rotation with revocation propagation is a future milestone.

The broader point

Q-day might be 2030. It might be 2032. It might be sooner, and we won’t necessarily know — the Google paper’s use of a ZK proof to redact the actual optimizations is a preview of what classified research on this topic probably looks like.

The NIST PQC standards (FIPS 203/204/205) are final. The libraries are production-ready. The implementation cost is real but not prohibitive — we did four repos in an afternoon. There’s no good reason to be issuing ECDSA device identity keys in 2026 for hardware that will be operating in 2032.

Start now while the fleet is small. The alternative is an emergency migration under pressure, with live robots, when someone with a CRQC decides your firmware attestation chain is interesting.

---

OpenCastor is an open-source robot runtime. RCAN is the Robot Communication and Autonomy Network protocol. Both are available on GitHub.