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

---

❤️ 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!