Show HN: MemCloud Security Deep Dive – How Devices Safely Share RAM over LAN
by vibhanshugarg | 2025-12-11 16:47:09+00:00
MemCloud is a distributed in-memory datastore I built that allows macOS/Linux machines on a LAN to pool their RAM into a shared ephemeral memory cloud. The most common question I received after launching it was: “How is this secure?”

This post is a detailed look at the authentication, encryption, and trust model used in MemCloud. This is not an introduction to the project; it’s a technical deep dive for people interested in protocols, distributed systems, and applied cryptography.

Documentation: https://memcloud.vercel.app/docs/cli

Repo: https://github.com/vibhanshu2001/memcloud

THREAT MODEL MemCloud assumes an untrusted LAN environment and defends against:

device impersonation

MITM attacks

replay attacks

unauthorized cluster joining

handshake/session hijacking

PERSISTENT IDENTITY KEYS (Ed25519) Every node generates a persistent Ed25519 identity keypair stored under ~/.memcloud/identity_key. These keys act like device certificates but without PKI overhead. Identity keys are only used for signing handshake transcripts, never for traffic encryption.

NOISE-STYLE HANDSHAKE (XX PATTERN) MemCloud uses a handshake sequence inspired by the Noise Protocol Framework (XX pattern):

Both sides start unauthenticated

Exchange ephemeral X25519 keys

Exchange random nonces

Build a transcript hash

Exchange encrypted identity proofs

Noise was chosen because it supports TOFU, mutual authentication, identity protection, and forward secrecy in a lightweight format suitable for P2P LAN systems.

TRANSCRIPT HASHING Each handshake message is appended to a transcript hash. This prevents replay, downgrade attempts, message tampering, and cross-session key reuse. The final transcript is mixed into session key derivation.

ENCRYPTED IDENTITY PROOFS Once ephemeral shared secrets are computed, each device signs the transcript hash with its Ed25519 identity key and sends the signature encrypted. Verification is performed against the claimed identity key. If verification fails, the connection is immediately rejected.

SESSION KEY DERIVATION (HKDF + CHACHA20-POLY1305) Session traffic keys are derived from the ephemeral DH shared secret + transcript hash using HKDF. Traffic uses ChaCha20-Poly1305 AEAD, chosen for speed and security on local networks. Every session gets unique traffic keys with forward secrecy.

TOFU (TRUST-ON-FIRST-USE) After cryptographic authentication succeeds, the user must approve the peer the first time it appears:

memcli consent [1] Allow Once [2] Trust Always [3] Deny

Trusted peers are stored in ~/.memcloud/trusted_devices.json. Even after trusting a device, each future session is fully authenticated; impersonation is not possible.

FAILURE MODES MemCloud rejects peers on:

signature mismatch

transcript mismatch

malformed handshake

untrusted identity

consent denial

No RAM quota or block storage rights are granted until after a fully authenticated session is established.

WHY NOT TLS? TLS is great but not ideal for MemCloud because:

It requires PKI, certificates, or a local CA

It is not naturally TOFU-friendly

It adds overhead unnecessary for LAN-bound P2P systems

Noise is simpler to embed directly inside the daemon

Noise-style handshakes offer mutual authentication, identity hiding, forward secrecy, TOFU support, and a lightweight binary format — making it a better fit for a distributed RAM engine.

OPEN QUESTIONS / FEEDBACK WANTED I’d love input on:

better trust revocation models

session resumption

formal verification directions

alternative TOFU approaches

potential attack surfaces I may have missed

This part of the project is evolving, and I’d appreciate thoughts from people who have built secure P2P systems or LAN protocols.

Repo: https://github.com/vibhanshu2001/memcloud

Docs: https://memcloud.vercel.app/docs/cli