Quantum-Resistant Horizen, Part 2: The Organization

This is the second post in a series where we lay out Horizen Labs' roadmap for migrating our infrastructure to quantum-resistant (QR) cryptography. Part 1 covered the Horizen protocol - the chain and its ecosystem. This one covers Horizen Labs as an organization: our servers, our keys, our developer tooling, and our funds. zkVerify will be addressed in the next and final blog post.

A different kind of post

Part 1 (Horizen chain and ecosystem) was mostly a list of things we are waiting for. Ethereum's PQ forks, Base and the Superchain tracking them, Caldera, AWS shipping a quantum-resistant attestation. Almost all of the heavy cryptographic lifting at the protocol layer belongs to somebody else, and our job there is to be ready to consume it the moment it arrives.

The Horizen Labs organization is the opposite. Our SSH configuration is ours. Our TLS termination, our signing keys, our secrets management, our custody procedures: all owned by us. So this post has a different character: it is less of a roadmap and more of a changelog, and where it is still a roadmap, the open items are open for reasons I will explain.

I'll use the same vocabulary as Part 1 without re-deriving it. Briefly:

• QR means the quantum-resistance property,
• PQC means the NIST-standardized schemes.
• HNDL is harvest-now-decrypt-later,
• TNFL is trust-now-forge-later (and I stress once again that the second one is badly underrated);
• (a)-type problems are ours to fix, (b)-type problems belong to an upstream, and we work them by documenting and requesting (b1), finding a replacement (b2), or explicitly flagging the limitation (b3).

The same disclaimer applies as last time: this is a status report, not a victory lap. Some of the most important items below are unresolved, and one of them is unresolved on purpose, which takes more explaining than a simple "we're working on it."

What we assessed

The QTA we ran internally covered Horizen Labs as an operating business rather than as a set of protocols: organizational structure and operating model, the core infrastructure and technology stack, the business lines and their expected lifespans, the high-level hardware and software cryptographic architecture, and the regulatory setting we work in. It ran off like we would run a QTA for an external client: a kickoff call with stakeholders, a structured questionnaire, a round of interviews, documentation collection, a preliminary report circulated for feedback, and a final pass. About ten person-days of business analysts, cryptographers, and infrastructure engineers.

What it deliberately did not do is enumerate everything. This is the point I made in Part 1: a Cryptographic Bill of Materials is a fine artifact and a terrible place to start. An inventory without a threat model and without a severity ordering does not tell you what to do, it tells you that you own a lot of cryptography, which you already knew. The job of a QTA is to establish where to look first, and what to skip.

In assessing severity, we weighed five things:

1. the level of exposure (data in transit versus at rest, access-controlled versus public-facing),
2. the lifespan of the protected information,
3. the value of a compromise to an adversary,
4. the cost of a compromise to the business, including reputational damage,
5. and the specific cryptography in use.

That produced five priority areas. Two of them (the Horizen chain and zkVerify) are the subject of the other posts in this series. That leaves three for this one: key management, PGP, and SSH. TLS sits alongside them because it turned out to be where the fastest wins were.

Harvest and forge, at an organizational scale

A chain's cryptography is public by construction. Every public key is on a ledger, every signature is in a block, and the adversary does not need to work for access. An organization's cryptography is mostly private, and that changes both what is worth harvesting and what is worth forging.

On the harvest side, the question is: what do we hold that is worth recording today and reading in 3-5 years? Administrative SSH sessions carry configuration, credentials, and whatever an engineer happened to type. Internal TLS sessions carry the same. Encrypted email is our rarest use of cryptography and our deepest: leadership decisions and, potentially, sensitive customer material. That's a narrow surface with serious implications.

Our overall conclusion was that HNDL risk sits at medium, and the reason is unglamorous: most of what we transmit has a shelf life shorter than any plausible time-to-quantum. A configuration detail from 2026 is not worth much in 2030.

With one large exception: the calculation changes completely when the harvested object is a key rather than a message. Messages age out. Keys don't, at least not on the same schedule. A long-lived symmetric master key wrapped under RSA and transmitted once is an HNDL target that never gets stale, and we have exactly that in our enclave key-delivery path. So does anything else where an asymmetric wrapper protects something durable - our Vault recovery threshold shares, for example, which are PGP-encrypted.

On the forge side, the picture is more challenging, and this is where an organization looks least like a chain. We rely on signatures for: fund custody across several chains, git commit signing, PGP tag verification gating deployments in CI/CD, SSH host and user authentication, and legally binding contracts with decade-long shelf lives. TNFL risk came out high, and it is the dominant risk in this assessment by a wide margin.

Here we see the same issue we discussed in Part 1. The reflexive line from the industry mantra is that HNDL is the emergency and signatures can wait. At an organizational scale we found something close to the reverse. Hybrid key exchange is just a configuration change, while quantum-resistant signatures, for most of what we sign, do not yet exist in any form we can deploy now. So the “changelog” half of this post is almost entirely HNDL, and the “open-items” half is almost entirely signatures. That's not a prioritization decision, but just a consequence of what is available.

TLS: done, with a caveat

All of our TLS certificates have been patched where the endpoint is ours to patch. The remainder sit behind Cloudflare, which negotiates hybrid ML-KEM key agreement by default and has done so since well before we asked.

Now the asterisk, because "we're behind Cloudflare, we're fine" is precisely the kind of half-truth this series exists to question. Cloudflare gives us QR key agreement. In the vocabulary above, that closes the HNDL gap, but leaves TNFL open. QR authentication (the certificates and signatures that prove the server is who it claims to be) is a separate problem, and on the visitor-to-edge connection it is still under development. Cloudflare is targeting 2029 for full QR coverage across its product suite, and has said it will turn things on by default as they land, which is the right posture and also means our exposure here tracks their schedule. Since mid-2026 they do support ML-DSA on the origin-facing side, through Authenticated Origin Pulls and Custom Origin Trust Store, and moving our origin connections onto that is an open item on our list.

So: TLS is HNDL-clean and TNFL-open.

SSH: key exchange done, authentication deliberately not

There are two very different stories here.

The key exchange half is finished.

Every SSH connection into our infrastructure now uses hybrid QR key exchange. The configured algorithm list is mlkem768x25519-sha256 and sntrup761x25519-sha512@openssh.com, and (this is the part that matters) nothing else. Both are hybrid QR. There is no classical-only method left in the list.

That last point was a deliberate choice rather than an accident of ordering. If you leave a classical key exchange enabled alongside the hybrid ones, you have created a downgrade path. An adversary who can influence negotiation gets to pick the weakest option you left on the table, and your monitoring will show a perfectly successful SSH connection with nothing to alert on. Hybrid KEX only counts when the fallback is a failed connection rather than a quieter one. This is a general lesson and it applies well beyond SSH: in a negotiated protocol, adding a good algorithm achieves nothing until you remove the bad ones.

We kept sntrup761 alongside ML-KEM because some of our older servers speak sntrup and not ML-KEM, and a handful of clients are in the same position. sntrup is on its way out now that ML-KEM has been standardized, and we will drop it when everything is upgraded, but a hybrid QR method we can actually negotiate beats a better one we can't. Plus, we do not have any reason to believe that sntrup is less cryptographically desirable than ML-KEM for our use case.

The authentication half is not finished, and this is where it gets interesting.

Host keys and user authentication keys are still Ed25519 and RSA. They are quantum-vulnerable. SSH's key exchange protects the session against harvesting; nothing protects the signature that proves who you are, and forging that signature can buy an adversary a root shell. The blast radius is enormous. An attacker mimicking our infrastructure could repoint our website, announce a nonexistent airdrop with total credibility, or sign whatever they liked as us. That is not only financial mayhem for customers and community, but also reputational damage you don't recover from.

The standard line, including in our own assessment when we wrote it, has been that there is simply no QR signature option for SSH and the only available move is to watch the standards track. That was true when we wrote it, but it stopped being completely true in July. In fact, OpenSSH 10.4, released in July 2026, added experimental support for mldsa44-ed25519: a composite scheme pairing ML-DSA-44 with Ed25519, so that breaking either one alone is not enough. This is genuinely the thing we said we were waiting for!

However, we are still not deploying it at this time:

• It is experimental and off by default. That is OpenSSH's own characterization.
• It implements draft-miller-sshm-mldsa44-ed25519-composite-sigs, an individual submission at version 00 that the SSHM working group has not adopted. The wire format can still change, and if it does, we would have to regenerate every key we issued.
• Almost nothing else speaks it. Not PuTTY, not the mobile clients, not our CI runners, and (critically for the next section) not the git forges. As far as I can determine, OpenSSH 10.4 is currently the only implementation in existence.

So this is an addition rather than a replacement, and a lab item rather than a fleet item. We are testing it, though we are not putting it in front of production yet. But the most important thing is that the clock that our prior assessment described as "not started" has started, which is good.

PGP: the deliberate non-migration

PGP is still in use at Horizen Labs in two contexts: git commit signing, which is mandatory for every developer and is the main use, and encrypted email, which is rare. It also underpins two things that matter more than either: release signing, and tag verification.

Commit and release signing carry no HNDL exposure at all, but a pure TNFL exposure: forge a signature and you can push arbitrary code through a pipeline whose entire trust relies on "was this tag signed by a known key?" Broad surface, no urgency in the harvesting sense, and very bad on the day it matters. Encrypted email is the mirror image: a narrow surface, real HNDL exposure, and the most sensitive content in the organization sitting behind it.

We have decided not to migrate our PGP keys at this stage for three reasons.

First, the PGP ecosystem is split.

PGP is in the middle of a format schism. I don’t want to turn this blog post into a PGP-schism one, but in a nutshell: the two main implementations of OpenPGP disagree on what packet format to adopt for new keys. There are two specifications: the IETF's RFC 9580, with v6 keys (Sequoia, rPGP, etc), and LibrePGP, with v5 keys, which is the one GnuPG follows and has done since 2023. For encryption, that is a real schism and a genuine choose-a-side problem: both specs have their own incompatible ML-KEM subkey format. For signing, there is nothing to choose between, because only v6 defines QR signatures at all, and it is not mainstream yet. GnuPG, instead, fell victim to the usual mantra I argue so much about: “HNDL is the only urgency”, therefore it has no QR signature support, and no immediate plans for it.

So, migrating our PGP commit signing to PQC is not just picking a side in a schism: It means leaving GnuPG, adopting an RFC 9580 implementation, re-issuing every developer key as v6, and getting the forges and the keyservers to accept them. On that last point, our keys are published on keyservers, because that is how a developer typically verifies a commit came from who it claims to - and keys.openpgp.org does not accept v5 LibrePGP keys at all, while Hockeypuck, which runs keyserver.ubuntu.com, handles neither v5 nor v6 yet.

Second, if we are paying for a toolchain migration anyway, the destination isn't PGP.

The choice in front of us was never "PGP with post-quantum keys versus SSH signing". It is "migrate to a different OpenPGP implementation, or migrate off OpenPGP". Framed that way, it answers itself. We agree with our own assessment and with the broader argument that PGP should not be the tool for new workflows. For internal git signing specifically, none of PGP's remaining advantages apply: we are not doing legacy interop, we do not need web-of-trust discovery or WKD key publication, and the verification set is our own developers. SSH-based commit signing and cosign for software provenance attestation is where we are going. Paying for a migration into a v6 OpenPGP stack we intend to leave means paying twice to arrive once.

Third, we are already using the best we can.

All our PGP keys are RSA-4096, which is substantially harder to attack, quantumly, than more “modern” elliptic curve-based keys like EdDSA. This is not to say that RSA-4096 is quantum-secure, but the world will fall apart well before these keys are compromised by QC.

So the judgment here is a bet about timing: I expect SSH to move quickly on quantum-resistant signatures. The evidence for that is reasonable: OpenSSH shipped experimental composite ML-DSA support in 10.4, roughly four months after we wrote an assessment saying no such option existed anywhere. The working-group activity is live, and OpenSSH shipped a hybrid post-quantum key exchange years ahead of most of the industry and made it the default before almost anyone else had a plan. If that trajectory holds, the window an RSA-4096 rotation is meant to patch will close before we would have finished migrating. If I am wrong about the timing, the intermediate step comes back onto the table. That is a substantial part of what the eighteen-month review is for, and it is the specific thing I will be watching.

A closing note, because it applies only to the other half.

Everything above concerns signing, and signing is what ties us to the SSH timeline. Our encrypted email does not depend on SSH at all, so it has its own exit, and unlike every other open item in this post, that exit is already open: age (spelled exactly this way) shipped native post-quantum recipients in December 2025. It uses ML-KEM-768 hybridized with X25519, which is the same primitive at the same parameter set as RFC 9980's mandatory-to-implement composite KEM. So, moving our encrypted email from OpenPGP to age would be a straightforward win cryptographically.

The contrast is instructive: One ecosystem has spent three years arguing about packet versions and still cannot offer a QR signature at all. The other decided to do QR encryption, wrote a specification, published test vectors, shipped it, and had other implementations following within weeks. I don't think it’s fair to blame the people involved for this difference. I think it is mostly about how much accumulated compatibility surface each one has to drag forward, which is itself a decent argument for preferring small, modern, single-purpose tools wherever you actually have the choice.

We have not made the move to age yet, and I am not announcing it as a decision. Encrypted email is our rarest cryptographic operation, which is precisely why it has not competed for attention against the items above. But it is also the one place where we hold real HNDL exposure on genuinely sensitive material, the exit is open, and the destination is already quantum-resistant.

Key management: the one we haven't touched

These are two problems under one heading: the keys that guard the money, and the keys that guard the secrets. This was the top-priority finding of the assessment and it is the area where we have the least to show, as we have not touched either yet.

The keys that guard the money

Fund management runs on a combination of self-custody and third-party custody: Gnosis Safe multisigs on secp256k1, signed via individual hardware wallets, across several EVM chains; Substrate pallet-multisig on sr25519 for zkVerify relay chain and VFlow parachain operations, including sudo; and a third-party custodian for unvested tokens, whose own quantum roadmap we have asked about and do not yet have. Thresholds are t-of-n, with signers distributed across countries.

All of it is 256-bit elliptic curves, so vulnerable to quantum attacks. And we have to make two further observations that the “threshold” policy tends to obscure.

First, multisig thresholds are operational security, not cryptographic diversity. A threshold Safe is excellent protection against one signer being compromised, coerced, or careless, but it is no protection whatsoever against the scheme itself breaking, because all keys share one scheme. Against a quantum adversary, t-out-of-N secp256k1 is one broken algorithm with extra steps.

Second, the standard partial mitigation recommendation that applies to all Web3 tech has already expired. The usual advice is to avoid exposing public keys and rotate to fresh addresses at every spend. It is sound advice, but for our operational wallets it no longer applies: Ethereum-style ECDSA lets you recover the public key from the signature (that is how the sender address is derived in the first place) so any signer who has ever executed a Safe transaction has published their public key by doing so. On the Substrate side it is more direct still: an sr25519 address is the 32-byte public key. The keys guarding our funds are, for practical purposes, already harvested and sitting in public waiting for a machine that can use them.

That is the TNFL scenario in its purest form. And, as I keep saying: if it happens, we will not know it was a quantum attack. A forged transaction looks exactly like a leaked key, an insider, or a wallet bug. We would work down the list of conventional explanations and never reach the right one.

The keys that guard the secrets

Our confidential compute enclaves receive their AES-256 master key from AWS KMS, and the recipient encryption on that path is RSAES-OAEP-SHA-256. That is classical public-key cryptography wrapping a long-lived symmetric key: the exception I flagged earlier, where the harvested object doesn't age out.

There is a subtlety here worth highlighting: AWS KMS endpoints do now negotiate hybrid ML-KEM TLS, and that is a real improvement to the outer channel. It does not fix this. The entire point of the Nitro recipient mechanism is that the plaintext is encrypted to the enclave's own public key, taken from the attestation document, inside the TLS session, precisely so that nothing in the middle, including the parent instance, can read it. That inner layer is RSA, and hybrid transport does not touch it, so fixing the transport and declaring the problem solved would be a mistake.

AWS has shipped ML-DSA key specs in KMS for signatures and hybrid ML-KEM on the endpoints, but QR-backed KMS keys, with KEM operations inside the HSM, are just a stated direction. Meanwhile, our Vault recovery shares are PGP-encrypted under a t-out-of-N threshold (but notice there is no age option here, as Vault expects PGP format encryption) and Vault auto-unseal runs through the same KMS.

What we're committing to

We are still searching for alternatives on both fronts. What we can commit to is the timeline: we will complete the key management migration within twelve months. For KMS it means a replacement with a credible QR key-wrapping path, which is probably a solvable procurement problem. For custody, it’s a bit more complicated: our safe is a smart contract, which depends on EVM to verify signatures, some parts of the contract are upgradable, others are not, like the proxy contract that points at the implementation. The eventual fix will most likely arrive through account abstraction and the Ethereum ecosystem rather than through anything we build. So, for now we can only move off arrangements that have no route to quantum resistance and onto ones that do, and ask written commitments from the vendors and the custodian who are currently in the position of being asked politely.

That is a less satisfying commitment than I would like to, but it’s all we can do at this stage.

Other stuff

Symmetric encryption and hash functions are fine. AES-256, ChaCha20-Poly1305, SHA-256, BLAKE2, Keccak. I made the argument at length in Part 1 and won't repeat it: Grover's quadratic speedup does not parallelize the way Shor-relevant attacks do, the physical resource requirements are absurd, and "halve the security bits" is a worst-case theoretical bound rather than an operational attack. Our disk encryption, our password manager vaults, and our secrets at rest are not at risk, and we are not going to spend engineering attention pretending otherwise while the actual fire is in the signature surface.

One last item that almost nobody thinks about: e-signatures on long-lived contracts. Legally binding documents signed with RSA or ECDSA today, with a ten-year-plus shelf life, need their signatures to still mean something at the far end of that window. You will occasionally see this described as harvest-now-verify-later, which isn't quite the phenomenon - nothing is being harvested. It's forge-later, and it is a genuinely open question for the entire e-signature industry rather than a Horizen Labs problem. I don't have an answer. I'm not sure anyone does yet.

Where we stand

Where this leaves us

At the organizational layer we have closed essentially all of our HNDL exposure on the surfaces we control. SSH key exchange is hybrid QR with no classical fallback, and TLS is either patched or sitting behind an edge that does hybrid key agreement by default. What remains is almost entirely signatures - which is exactly the shape Part 1 predicted, and exactly the half of the problem the industry keeps deferring on the grounds that it can be deferred.

Of the remaining items, two are blocked on other people. SSH authentication, where the standard has only just appeared and almost nothing implements it. And custody, where no vendor sells the thing we need and we are reduced to asking.

And one (PGP) is a decision rather than a blockage, which is why it got a long discussion. We could migrate those keys this quarter, but it would be a toolchain migration rather than a key rotation, onto an OpenPGP stack we intend to leave anyway, and then a second migration to SSH signing not long after. Doing nothing is sometimes the correct engineering decision.

Next in this series: zkVerify. It is the most technically interesting of the three, and the one where the least of the answer is available off the shelf.

Questions, corrections, and "actually, you're wrong about X" are all welcome - preferably the third kind, since that's how the good stuff gets found.