Why Local Encryption Matters (and "Encryption at Rest" Often Doesn't)
Most cloud platforms say they encrypt data at rest. That statement is often true—but incomplete.
The engineering question you should ask is:
Who can produce the decryption key under real-world conditions?
If the provider can decrypt (because they manage keys, HSMs, or key escrow), then the security outcome depends on:
- Provider internal access controls
- Insider risk
- Breach blast radius
- Legal compulsion / lawful access regimes
- Configuration errors and multi-tenant isolation
In other words: encryption at rest is frequently "encryption under provider control."
Local (client-side) encryption changes the trust boundary
Local encryption means encryption happens on your endpoint before any provider sees data. Cloud storage becomes a dumb blob store:
- It can store ciphertext
- It can sync ciphertext
- It cannot interpret ciphertext
That is the core of a zero-knowledge posture: cloud accounts can be compromised, providers can be compelled, and you still don't hand over plaintext.
Necron's model: encrypt locally, keep keys on hardware
Necron's vault design formalizes this separation:
- Ciphertext lives in one or more user-chosen storage locations (local folders, cloud-synced folders).
- Key material lives on a hardware dongle.
- Decrypt requires possession of that dongle; the vault UX is provided by an in-app "vault view," not by mounting plaintext into a provider-controlled environment.
A key detail: the vault is designed so that filenames and directory structure are not exposed to storage providers in plaintext. Stage 1 uses an obfuscated on-disk layout (n/, o/, sys/) where user-facing names live inside sealed node objects, not as real filesystem names.
Threat-model comparison: what local encryption protects against
Cloud account takeover
If an attacker gets your cloud credentials, they can:
- Delete data
- Ransom data (availability attack)
- Copy ciphertext
Local encryption does not prevent deletion (availability), but it does prevent confidentiality loss: copied ciphertext remains useless without keys. Necron reinforces this with integrity-aware vault objects, so tampering is detected when decrypting.
Provider-side compromise / insider access
With provider-managed keys, "encryption at rest" doesn't stop:
- Rogue admin access
- Compromised internal services
- Mistaken access grants
With client-side encryption + hardware-held keys, these vectors largely stop at ciphertext.
Legal compulsion
If the provider holds keys, they can decrypt when compelled. If keys never leave your control, providers have much less to hand over.
Integrity matters: confidentiality-only encryption is insufficient
A practical encryption system must detect:
- Bit flips (sync glitches, disk errors)
- Malicious edits (tampering)
- Object swaps (replacing one ciphertext object with another)
Necron's architecture explicitly treats integrity and repair as part of vault correctness (not an optional feature), pairing AEAD payload integrity with metadata sealing and identity binding.
"Local encryption" done badly still leaks
Client-side encryption can still fail if:
- Plaintext is cached to disk accidentally
- Temp files persist
- Indexing/search services ingest plaintext
- Filenames leak meaningful metadata
A vault architecture should be explicit about where plaintext can exist. The design choice to build the tree view from sealed metadata objects (without scanning payload objects) is partly about performance, but also reduces unnecessary plaintext handling.
FAQs
Isn't cloud encryption at rest enough?
It depends on who holds the keys. If the provider can decrypt, your security depends on the provider's controls and obligations.
Does local encryption make cloud storage useless?
No. Cloud storage remains useful for sync and availability; it just stores ciphertext, not plaintext.
What if my cloud account is compromised?
Attackers can copy or delete ciphertext. Confidentiality remains intact if keys remain offline/hardware-bound. Availability requires backups/mirroring (see multi-cloud mirroring).