FNP End-to-End Encryption & Zero Trust Architecture
fnp advanced 7 min read
ELI5
FNP uses five layers of encryption, like a Russian doll of security. Each layer protects against different threats: network eavesdropping, server compromise, future quantum computers, and more. Even if one layer is broken, the others keep your data safe.
Technical Deep Dive
Five Encryption Layers
| Layer | Technology | Purpose | Key Lifetime |
|---|---|---|---|
| 1. TLS 1.3 | ECDHE (elliptic curve) | Network encryption (HTTPS) | Session |
| 2. Kyber-1024 | Post-quantum KEM | Content encryption | 1 year |
| 3. M²-ORE | Order-revealing | Position ordering (server-side) | 1 month |
| 4. Halo2 | Zero-knowledge proofs | Operation authenticity | Per-op |
| 5. Dilithium | Post-quantum signatures | Identity & non-repudiation | Per-session |
Encryption flow:
Plaintext (user's text) ↓ [Kyber]Symmetric key + ciphertext ↓ [M²-ORE encrypt positions]Encrypted positions + encrypted content ↓ [Halo2 proof]Proof + signature ↓ [Dilithium sign]Final operation with signature ↓ [TLS 1.3 transport]Over HTTPS to serverflowchart TD PT["Plaintext (user input)"] L2["Layer 2 — Kyber-1024 KEM<br/>(content)"] L3["Layer 3 — M²-ORE<br/>(positions)"] L4["Layer 4 — Halo2 proof<br/>(authenticity, blind)"] L5["Layer 5 — Dilithium signature<br/>(identity)"] L1["Layer 1 — TLS 1.3 ECDHE<br/>(transport)"] SRV["Server (blind)"] PT --> L2 --> L3 --> L4 --> L5 --> L1 --> SRVZero Trust Model
Principle: Never trust, always verify.
Key tenets:
- Verify every operation — Even trusted agents’ operations are cryptographically verified
- Assume compromise — Design for “what if server is breached?”
- Least privilege — No operation gets more access than necessary
- Continuous verification — Every message verified, no implicit trust
Implementation in FNP:
Zero Trust Checklist:✓ TLS handshake: Verify server certificate✓ Session start: Encapsulate shared secret with Kyber✓ Every operation: Verify Dilithium signature✓ Merge: Verify Halo2 proof blind (no decryption)✓ Decryption: Only decrypt if authorized (key agreement)✓ Replay: Verify unique (operation_id, clock) pair✓ Audit: Log all verifications for later reviewKey Rotation Strategy
Kyber keys (content encryption):
- Rotate yearly
- Old key encrypted with new key (reencryption)
- Provides forward secrecy: old keys can be deleted
M²-ORE keys (position ordering):
- Rotate monthly
- Frequency attacks accumulate with time
- Monthly rotation limits information leakage
Dilithium keys (signatures):
- Rotate per-session (automatically at login)
- Limits impact of long-term key compromise
Rotation procedure:
1. Generate new key (new_key = KDF(old_key, "rotation"))2. Mark old_key as deprecated3. Encapsulate all data with new_key4. Delete old_key after transition period (30 days)5. Log rotation for audit trailstateDiagram-v2 [*] --> Active Active --> Deprecated: rotation event Deprecated --> Reencrypting: re-encapsulate data with new_key Reencrypting --> Retired: 30-day transition window elapsed Retired --> [*] Active --> Active: in-useDevice Compromise Scenarios
Scenario: Alice’s laptop is stolen
Without FNP:
- Attacker reads all documents (if encrypted on disk)
- Attacker impersonates Alice (if password compromised)
With FNP:
- Attacker reads encrypted content (Kyber key compartmentalized, not on disk)
- Attacker can forge documents for this session (Dilithium key per-session)
- Attacker cannot forge documents from future sessions (new Dilithium key at login)
- Attacker cannot decrypt other users’ data (different Kyber keys per user)
Impact: Only Alice’s current-session documents are at risk; other users, other sessions, and past archives remain secure.
Key Terms
- Defense in depth → Multiple overlapping security layers; failure of one doesn’t compromise all
- Forward secrecy → Compromise of long-term keys doesn’t decrypt past sessions
- Compartmentalization → Keys stored separately; compromise of one key doesn’t reveal others
- Session-scoped keys → Keys tied to login session; new session = new keys
Q&A
Q: If TLS is already encrypted, why add more layers? A: TLS only protects in-transit. Layers 2-5 protect data at-rest (if server is breached) and protect against quantum computers (TLS uses ECDHE, which is not post-quantum).
Q: What if all five layers are broken? A: Extremely unlikely. Breaching both Kyber (post-quantum KEM) and Dilithium (post-quantum signatures) simultaneously would require breakthroughs in lattice cryptography — a global cryptographic crisis. Single-layer compromise is much more likely and doesn’t expose all data.
Q: Does key rotation slow down the system? A: Negligible. Rotation is done offline (at login for session keys, monthly batch for content). Users don’t experience latency. Reencryption is amortized.
Examples
FNP’s five layers are like a bank vault: outer door (TLS), manager’s office (Kyber), personal safe (M²-ORE), proof of ownership (Halo2), and signed receipt (Dilithium). Even if a burglar breaks in, they face five independent obstacles. Breaching one doesn’t guarantee access to deeper layers.
neighbors on the map
- FNP Byzantine Fault Tolerance & Threat Model understanding FNP's Byzantine resilience