One-Time Pad: The Gold Standard (and Why Real Systems Use OTP-Inspired Designs)
The one-time pad (OTP) is unique: under correct use (truly random pad, pad length ≥ message length, never reused), the ciphertext leaks zero information about plaintext.
That's the theoretical "gold standard."
The practical issue is not the math. It's the operational requirement:
- You must store and protect key material at least as large as the data
- You must ensure no reuse of pad bytes (ever)
- You must maintain reliable accounting and recovery—without creating new attack surfaces
The implementation cliff: pad distribution and reuse prevention
OTP is straightforward on paper and brutal at scale in software systems because:
- "Never reuse pad bytes" implies a global allocator/journal with crash safety
- Multi-device usage creates synchronization and concurrency hazards
- Recovery workflows easily introduce accidental reuse
- The moment you replicate pads for redundancy, you've increased attack surface
This is why most production-grade storage systems use computational security (AEAD) rather than pure OTP.
The practical alternative: AEAD + OTP-inspired blast-radius control
Necron's current vault architecture uses AEAD (XChaCha20-Poly1305) for file payloads, not OTP streams, specifically to avoid OTP's operational failure modes while still keeping the key model hardware-bound and per-file separated.
Per-file independence as the "useful part" of OTP
A pure OTP makes every message statistically independent (because each uses fresh pad material). In practical systems, you can target a similar outcome—small blast radius—by ensuring:
- Each file is encrypted under a distinct key
- Keys are derived with domain separation and identity binding
- Compromise does not cascade
Necron Stage 1 vault does this by deriving a stable per-file payload key from dongle key material:
- Each file stores an offset to a stable 64-byte slice in the dongle key file.
- HKDF derives a file payload key using explicit binding inputs (vault identity, file identity, dongle identity).
This approach preserves per-file compartmentalization without forcing "pad exhaustion" and without requiring a global "never reuse bytes" allocator across the entire vault.
Where OTP still makes sense
OTP can still be appropriate when:
- Message sizes are small and predictable
- Distribution is controlled (pre-shared pads, physical transfer)
- You can enforce single-use policies reliably
- The environment is offline/air-gapped and operationally disciplined
In most consumer/SMB storage products, those assumptions do not hold.
Avoiding misleading claims
If you market "OTP-like" properties, be precise:
- Pure OTP: key length equals message length; no reuse; perfect secrecy.
- OTP-inspired architecture: large hardware-held key material pool + per-file keys + strong AEAD + strict identity binding.
Necron's documented design explicitly says key material is used as a key source and is not consumed proportional to file size. That is incompatible with pure OTP semantics—but entirely compatible with strong AEAD-based security.
FAQs
Is OTP "quantum-proof"?
OTP is information-theoretically secure if implemented perfectly. The hard part is operational correctness (pad generation, distribution, and non-reuse).
Does Necron use pure OTP?
Necron's vault design uses AEAD for payload encryption and derives per-file keys from hardware-held key material; key material is not consumed proportional to file size.
Why not do pure OTP for everything?
Because enforcing "never reuse pad bytes" and managing pad-sized key distribution at scale introduces fragile operational failure modes that are often worse than the threat you're trying to mitigate.