When I released MemCloud (a distributed RAM engine for macOS & Linux), the biggest question I got was:
“Isn’t letting other devices store your RAM risky? How is it secured?”
So here’s a deep-dive into the authentication, encryption, and trust model behind MemCloud — written for engineers who love protocols, threat models, and cryptographic design.
This post focuses purely on the Security & Authentication layer.
(If you're new to MemCloud, see the intro blog — this assumes familiarity.)
🧩 Threat Model
Before designing the protocol, I outlined real-world LAN threats:
| Threat | Example |
|---|---|
| Impersonation | Rogue device pretends to be a trusted peer |
| MITM Attack | Attacker intercepts or mutates handshake traffic |
| Replay Attack | Reusing old handshake messages |
| Unauthorized Memory Access | Device silently joins the cluster |
| Session Hijacking | Stealing or predicting traffic keys |
MemCloud’s protocol addresses all of them.
🛂 1. Persistent Identity Keys (Ed25519)
Every device has a long-term identity keypair:
~/.memcloud/identity_key
- Ed25519 (fast + secure)
- Only used to sign handshake transcripts
- Never used for encryption
This behaves like a device certificate without the complexity of PKI.
🔐 2. Noise-Style Handshake (XX Pattern)
MemCloud uses an authentication flow inspired by the Noise Protocol Framework — specifically Noise_XX, chosen because:
- Both sides begin unauthenticated
- Supports Trust-On-First-Use (TOFU)
- Offers mutual authentication
- Ensures forward secrecy
Simplified handshake:
A → B : eA, nonceA
B → A : eB, nonceB
A → B : identity proof (encrypted)
B → A : identity proof (encrypted)
Where eA and eB are ephemeral X25519 public keys.
📜 3. Transcript Hashing
Every handshake message is hashed into a transcript:
H = Hash(H || message)
This prevents:
- Replay attacks
- Downgrade attacks
- Cross-session confusion
- MITM tampering
The transcript is later fed into key derivation.
🧾 4. Encrypted Identity Proofs
Once ephemeral keys are exchanged, both sides compute:
shared_secret = DH(eA, eB)
Using this encryption key, each device sends:
signature = Sign(TranscriptHash, IdentityKey)
This signature:
- is encrypted
- is bound to the transcript
- cannot be replayed
- proves identity with forward secrecy
If signature verification fails → connection closed immediately.
🔑 5. Session Key Derivation (HKDF)
Final traffic keys are derived using:
session_key = HKDF(shared_secret + transcript_hash)
Properties:
✔ Unique keys per session
✔ Handshake keys ≠ traffic keys
✔ Forward secrecy (ephemeral DH)
✔ Resistant to key compromise
Traffic encryption uses:
ChaCha20-Poly1305 AEAD
Perfect for high-speed LAN communication.
👁 6. Trust-On-First-Use (TOFU)
Requesting device:
On first contact, the user must explicitly approve the peer:
Trusted peers are stored in:
~/.memcloud/trusted_devices.json
Future connections:
- Still cryptographically authenticated
- Skip interactive approval
- Cannot be silently spoofed or replaced
🚫 What Happens When Auth Fails?
MemCloud rejects the session if:
- identity signature fails
- transcript mismatch occurs
- handshake is malformed
- device is untrusted
- the consent layer blocks authorization
Rejected peers cannot:
- read your RAM
- receive block data
- join the cluster
- impersonate a previous peer
🔍 Why Not TLS?
TLS is powerful, but not ideal for a P2P LAN memory engine.
❌ Requires PKI or certificate distribution
MemCloud is designed to be zero-config.
❌ Not optimized for TOFU
Noise is.
❌ More overhead for LAN P2P
MemCloud aims for sub-10ms latency.
✔ Noise-style handshake advantages:
- Mutual authentication
- Identity hiding
- Forward secrecy
- TOFU support
- Lightweight binary protocol
- Perfect for peer-to-peer systems
🧪 Fuzzing & Attack Testing
I tested the handshake against:
| Attack Attempt | Result |
|---|---|
| Replay | Blocked via transcript mismatch |
| MITM | Blocked (identity proof mismatch) |
| Impersonation | Blocked (signature invalid) |
| Downgrade attempt | Impossible |
| Payload tampering | Blocked (MAC failure) |
So far the protocol has held up extremely well in real-world LAN conditions.
🛠 Security Roadmap
Planned improvements:
- 🔄 Trust revocation broadcasting
- 🖥 GUI trust manager
- 🛡 Optional hardware-backed identity keys
- 🔁 Session resumption
- 📦 Encrypted replication across peers
Contributors welcomed.
📦 Source Code
👉 Authentication Code: /memnode/src/net/auth
👉 Main Repo: https://github.com/vibhanshu2001/memcloud
👉 Documentation: https://memcloud.vercel.app/docs/cli
👉 CLI Trust Manager: memcli trust
❤️ Final Thoughts
MemCloud may look simple on the surface:
“Devices sharing RAM over LAN.”
But underneath is a carefully engineered secure protocol designed to make that actually safe.
If you'd like a follow-up on the:
- P2P binary protocol
- memory isolation model
- quota enforcement
- zero-copy streaming design
Just let me know!
Top comments (0)