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.