🔒 Inside MemCloud’s Secure Peer Authentication: How Devices Safely Share RAM Over LAN

Source: Dev.to

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?”

Below is 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

MemCloud’s protocol addresses all of them.

Identity Keys

Every device has a long‑term identity keypair stored at:

~/.memcloud/identity_key

• Algorithm: Ed25519 (fast + secure)
• Purpose: Only used to sign handshake transcripts – never for encryption.

This behaves like a device certificate without the complexity of PKI.

Authentication Flow (Noise XX)

MemCloud uses an authentication flow inspired by the Noise Protocol Framework, specifically the Noise_XX pattern, 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)

eA and eB are ephemeral X25519 public keys.

Each handshake message is hashed into a transcript:

H = Hash(H || message)

This prevents replay, downgrade, and cross‑session attacks, and the transcript is later fed into key derivation.

Key Derivation & Identity Proof

1. Compute the shared secret:

   shared_secret = DH(eA, eB)

2. Derive the session key:

   session_key = HKDF(shared_secret + transcript_hash)

3. Each device signs the transcript hash with its long‑term identity key:

   signature = Sign(TranscriptHash, IdentityKey)

   • The signature is encrypted, bound to the transcript, and cannot be replayed.
   • If verification fails, the connection is closed immediately.

Traffic Encryption

Final traffic keys are derived as shown above and used with ChaCha20‑Poly1305 AEAD, which is perfect for high‑speed LAN communication.

Trusted Peers

Trusted peers are stored in:

~/.memcloud/trusted_devices.json

Future connections to a known peer:

• Remain cryptographically authenticated
• Skip interactive approval
• Cannot be silently spoofed or replaced

What Happens When Auth Fails?

MemCloud rejects the session if any of the following occur:

• 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:

• MemCloud aims for zero‑config; Noise provides that out of the box.
• Desired latency is sub‑10 ms; Noise’s lightweight binary protocol is faster.
• Requirements such as mutual authentication, identity hiding, forward secrecy, and TOFU are naturally satisfied by the Noise pattern.

Test Results

So far the protocol has held up extremely well in real‑world LAN conditions.

Planned Improvements

• 🔄 Trust revocation broadcasting
• 🖥 GUI trust manager
• 🛡 Optional hardware‑backed identity keys
• 🔁 Session resumption
• 📦 Encrypted replication across peers

Contributors are welcomed.

Resources

• Authentication Code: memnode/src/net/auth
• Main Repository:
• Documentation:
• CLI Trust Manager: memcli trust

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, or zero‑copy streaming design, just let me know!