Understanding Post-Quantum Encryption (and What Actually Breaks)
Quantum computing doesn't need to be "here" for the risk to be real. A capable adversary can exfiltrate ciphertext today and keep it until the cryptography protecting it becomes weaker (or obsolete). That threat model has a name: harvest now, decrypt later.
The important nuance is that not all cryptography is equally exposed:
- Public-key cryptography (RSA, classical ECC) is structurally vulnerable to a sufficiently large, fault-tolerant quantum computer (via Shor-style attacks).
- Symmetric cryptography (AEAD, MACs, hashes) is affected more modestly (via Grover-like quadratic speedups) and can be "sized up" with longer keys.
That distinction is why post-quantum security is not only "swap algorithms," but architect for the failure mode you care about: long-term confidentiality under powerful future compute.
What breaks first: key exchange and public-key identity layers
Most "data encryption" stacks rely on public key cryptography somewhere in the pipeline:
- TLS handshakes and key exchange
- Device enrollment and certificate chains
- Sharing keys to collaborators
- Password managers and secure messaging identity models
In a harvest-now scenario, the biggest risk is often not the data cipher—it's how the key was negotiated and recorded.
System-design implication: If your architecture can avoid "long-lived public-key secrets," you reduce exposure. One straightforward way is a hardware-held symmetric key model where decryption requires physical possession rather than remote key exchange.
What holds up: symmetric AEAD (with appropriate key sizes)
Symmetric encryption doesn't "fall over" the way RSA/ECC would under Shor-style attacks. The post-quantum adjustment is primarily about security margin:
- Grover provides a square-root speedup against brute force.
- A rough engineering rule: 256-bit symmetric keys retain ~128-bit post-quantum security margin.
That margin is still strong for long-term confidentiality, provided your system avoids key reuse hazards and implements integrity correctly.
Architecture-level post-quantum security (what Necron is optimizing for)
When someone says "post-quantum encryption," they often mean "use post-quantum public key algorithms." That's necessary for some protocols, but it's not sufficient for storage security. Storage systems live or die by:
- Key separation (blast-radius control)
- Tamper evidence / integrity
- Metadata leakage control
- Recovery and operational security
1) Use AEAD for payload confidentiality and integrity
Necron's vault storage model uses AEAD for file payloads (confidentiality + authentication tags), so corruption/tampering is detected on decrypt. The architecture explicitly calls out AEAD payload protection and multi-location integrity behavior.
2) Per-file key separation (limit blast radius)
Necron's Stage 1 vault derives per-file payload keys from dongle key material using HKDF, binding them to vault/file identity. This means compromise of one derived key does not automatically compromise other files (no "single AES key for the whole vault" failure mode).
A concrete example from the design:
- A file stores a stable pointer to a 64-byte seed slice in the dongle key file.
- That slice feeds HKDF with explicit domain separation inputs (vault ID, file ID, dongle identity) to derive the payload key.
3) Treat metadata as a first-class attack surface
Post-quantum discussions often ignore metadata, but real adversaries love it:
- Filenames and folder structure
- Timestamps
- Object identifiers
- "Which files exist" leakage
Necron's Stage 1 vault layout separates node metadata (directory and file nodes) from content objects and seals node objects using deterministic mechanisms suited for small metadata objects, while keeping the UI tree scan fast.
4) Avoid "key exhaustion" semantics that create operational failure modes
Earlier OTP-style designs can introduce pad exhaustion constraints. Necron's current vault design uses dongle key material as a key source, not as a one-time pad stream, so it is not consumed proportional to file size (no vault going read-only due to "pad depletion").
The practical takeaway
Post-quantum security is not a sticker you apply to a cipher suite. A quantum-resistant storage architecture typically looks like this:
- Use symmetric AEAD with high security margins
- Derive per-file keys (no monolithic vault key)
- Cryptographically bind objects to identities via AAD
- Minimize metadata leakage
- Make integrity checks and repair part of the system (not an afterthought)
Necron's vault design explicitly targets these properties: AEAD payloads, per-file key derivation, and integrity-aware mirroring.
FAQs
Does quantum computing break all encryption?
No. It most directly threatens classical public-key schemes (RSA/ECC). Symmetric crypto is impacted more modestly and can be sized up with longer keys.
Is "post-quantum" just choosing new algorithms?
No. For storage, architecture matters: key separation, integrity, metadata protection, and operational controls.
Why focus on symmetric AEAD for post-quantum storage?
Because it retains strong security margins under plausible quantum speedups and avoids the most fragile part of many stacks: public-key key exchange for long-lived secrets.