Security levels and quantum status
How strong each primitive is today, which ones a quantum computer would break, and what an attacker could and could not do if one existed.
Everything Umbra keeps private is already encrypted with post-quantum cryptography: notes under ML-KEM-768, and the shares and openings sent to its enclaves under hybrids that include ML-KEM. What still rests on elliptic curves is the proof system and a handful of signature schemes. Those check who approved a transaction and that it follows the rules at the moment it lands; none of them protects stored data. So each can be replaced when it needs to be, nothing users hold has to move, and nothing published before then becomes readable.
Primitive by primitive
The classical figures are the levels each primitive's standard or specification states, except for BN254, whose figure is the current published estimate. "Broken" means a large quantum computer running Shor's algorithm would solve the problem the primitive rests on.
| Component | Classical security | Quantum status | What breaking it would allow |
|---|---|---|---|
| Groth16 proofs on BN254 | Roughly 100 bits | Broken | Forging proofs: spending notes you do not own, creating value, withdrawing without funding |
| BLS combined attester signature on BN254 | Roughly 100 bits | Broken | Forging the combined attester signature, which removes the attesters' veto; a valid proof is still required |
| Zone signatures, EdDSA-Poseidon on BabyJubJub | Discrete logarithm in a subgroup of about 2²⁵¹ points | Broken | Forging a zone authority's approval |
| Wallet signatures, Ed25519 | About 128 bits (RFC 8032) | Broken | Signing as a main wallet or platform wallet |
| Attestation certificates, ECDSA P-384 | 192 bits | Broken | Forging an AWS attestation, so that a key not generated in an approved enclave could be admitted |
| Note encryption, ML-KEM-768 with AES-256-GCM | NIST category 3 | No known quantum attack | Reading encrypted notes |
| Guardian transport, ML-KEM-1024 with X25519 | NIST category 5, and about 128 bits for X25519 | Holds while ML-KEM-1024 holds | Reading viewing-key shares in transit; both halves must be broken |
| Fee enclave transport, ML-KEM-768 with X25519 | NIST category 3, and about 128 bits for X25519 | Holds while ML-KEM-768 holds | Reading fee openings in transit; both halves must be broken |
| Enclave response signatures, ML-DSA-87 with Ed25519 | NIST category 5, and about 128 bits for Ed25519 | Holds while ML-DSA-87 holds | Forging a guardian node's response; both halves must be broken |
| Poseidon over BN254 | Designed for 128 bits | No known quantum attack beyond generic speed-ups | Breaking commitments: opening one to a second value, or forging a Merkle path |
| Keccak-256 | 128 bits against collisions | No known quantum attack beyond generic speed-ups | Two different transactions with the same digest, so signatures on one would cover the other |
| Sender record encryption, a keyed Poseidon keystream | Rests on Poseidon as a pseudorandom function | No known quantum attack beyond generic speed-ups | Reading sender records |
| Shamir 2-of-3 sharing | Unconditional | Unaffected | Nothing: one share reveals nothing to anyone, whatever their computer |
BN254 was designed for 128-bit security. Improved attacks on the family of pairing-friendly curves it belongs to have lowered current estimates to roughly 100 bits.
Replacing what is not post-quantum
Every row the table marks as broken is either a signature or the proof system. Replacing one changes code and keys; it does not change a note, a balance, an identity or anything a user stores.
Signatures Umbra controls
The combined attester signature and zone approvals are authorisation checks. Each says who approved one transaction, and matters only while that transaction lands. Swapping the attesters' BLS signature for a post-quantum one is an upgrade of the programs that check it and new keys for the attesters. Zone approvals are checked inside the transaction proof, so swapping their scheme is a change to that circuit, made alongside its new verifying key. Guardian nodes already sign their responses with ML-DSA-87 alongside Ed25519, so they need no change.
Post-quantum signatures are kilobytes rather than tens of bytes, and they do not add together the way BLS signatures do, so six of them would not fit in one Solana transaction beside the proofs. They would be checked ahead of the transaction, across several transactions, the way the P-384 verifier already checks one attestation certificate in steps.
Signatures Umbra does not control
Two broken schemes belong to the platforms Umbra runs on. Wallet signatures are Solana's Ed25519, and attestation certificates are signed by AWS with ECDSA P-384. Umbra moves when Solana and AWS do. Keys derived from your wallet signature explains why a broken wallet key still does not reveal your Umbra keys.
The proof system
Groth16 can be replaced by a hash-based proof system such as Spartan with WHIR, which proves Umbra's circuits as they are; post-quantum proofs describes the proof of concept and what on-chain verification still needs. The same property means Umbra can move to a faster proof system when one arrives: the circuits fix what is proved, so the commitments, nullifiers and trees built on them carry over.
Harvest now, decrypt later
An attacker can copy everything public today and wait for better computers. For Umbra that means the chain, the published encrypted notes and anything intercepted in transit.
If a quantum computer large enough to run Shor's algorithm at scale came to exist, its owner could, from then on:
- forge Groth16 proofs and the combined attester signature, and so take value from the pool;
- forge zone approvals and AWS attestations;
- sign as any Solana wallet whose public key is known.
Those are attacks on the future, and they can be headed off by replacing the proof system and signatures before such a computer exists, as the section above describes. The same attacker could not:
- decrypt notes published before then, which rest on ML-KEM-768;
- read viewing-key shares or fee openings captured in transit, which rest on hybrids that include ML-KEM;
- learn anything from proofs already published: for a proof made under a correctly formed proving key, Groth16's zero-knowledge property does not depend on any hardness assumption, so it holds against unlimited computing power.
One limit to this: note encryption uses ML-KEM-768 alone, with no classical key exchange beside it, so if ML-KEM-768 itself fell, notes would have no second layer.
Keys derived from your wallet signature
Every Umbra key you hold comes from one Ed25519 signature: your wallet signs a fixed notice, and HKDF-SHA512 turns those 64 bytes into your spending, viewing and encryption keys (see the account signature). The signature is never published. The question is whether a quantum attacker who breaks your wallet's public key could make it again.
This derivation is not part of the protocol. The pool program and the circuits see only keys and the commitments made from them; nothing on chain or in a proof checks where those keys came from, or requires them to come from a signature at all. Deriving everything from one wallet signature is how the Umbra applications and their SDK do it, so that a wallet alone can recover an account. Another client could generate keys at random or derive them some other way, and this section applies only to keys made the Umbra way.
How Ed25519 signs
An Ed25519 private key is a 32-byte seed. Its SHA-512 hash is split in two. The first half becomes the secret scalar, and the public key is that scalar times the curve's base point. The second half, the prefix, never enters the public key. To sign a message, the wallet hashes the prefix with the message to get the nonce, publishes the nonce times the base point, and combines the nonce with the scalar. Because the nonce comes from the prefix and the message alone, the same wallet signing the same notice always gives the same 64 bytes, which is what lets you recover your account by signing again.
What a quantum computer recovers
Shor's algorithm recovers the secret scalar from the public key. It does not recover the seed or the prefix: both sit behind SHA-512, and the public key depends on the scalar alone.
To make your account signature again, an attacker needs its nonce, and the nonce is a SHA-512 hash of the prefix and the notice. Without the prefix it cannot be computed. With the scalar alone the attacker can make a different valid signature over the notice, using a nonce of its own, but the bytes differ, and HKDF over different bytes derives unrelated keys: an empty account, not yours. The SDK checks that a signature is valid, but what derives your keys is the exact bytes, not their validity.
Signatures your wallet has published do not help either. Every Solana transaction you have signed is public, and with the scalar an attacker can work out the nonce behind each one. Each of those nonces is a SHA-512 hash of the prefix and a different message, so getting the prefix back means inverting SHA-512 over 256 unknown bits. Grover's algorithm cuts a search of that size to about 2¹²⁸ steps, which stays out of reach.
What this rests on
- Your wallet follows RFC 8032. The argument needs the wallet to derive each nonce from the prefix, as the standard specifies. The SDK accepts only 64-byte Ed25519 signatures, because a scheme that is not deterministic would derive a different account next time, but it cannot see how a wallet computed its nonce.
- The platform wallet holds nothing upstream. The platform wallet is an Ed25519 key derived from your wallet seed with SLIP-0010, whose hardened steps are HMAC-SHA512. Breaking its public key lets an attacker sign as the platform wallet, but going back from it to the seed, and from there to your other keys, means inverting HMAC-SHA512.
- It covers your keys, not your wallet. The attacker can still sign as your main wallet and move what it holds in public. What stays out of reach is the signature behind your Umbra keys, and with it your notes and history.
- The seed and the signature stay private. Anyone who has your wallet's seed phrase, or the account signature itself, has the account on any computer.
Related
Last updated
Trusted execution
A short primer on enclaves, measurements and attestation, and how Solana programs check an enclave before its key may sign.
Everything you own
The objects that make up an Umbra account, where each one lives, who can see it and how it comes back, and what Umbra's infrastructure holds about you.