livv logolivvv0.2.1
how it works

How livv Works

Your wallet is your identity. Your device does all the encryption. The server is blind — it relays ciphertext, never plaintext.

01

Authentication

No email, no password — just your Ethereum wallet

step 1

Connect Wallet

Click 'Connect Wallet' to link your MetaMask. livv requests your public address — nothing else.

step 2

Sign a Message

Your wallet signs a challenge message to prove ownership. This signature never leaves your browser.

step 3

Get Session Token

The server verifies the signature and issues a short-lived JWT. Your wallet address is your only identity.

02

End-to-End Encryption

Messages are encrypted on your device before they leave

✏️You typeplaintext
🔒Encryptedon your device
☁️Server relaysciphertext only
🔓Peer decryptson their device

The server is a relay, not a reader. It has no keys, no plaintext, no ability to decrypt — not now, not retroactively.

03

Key Derivation

Sign once, derive many — no wallet popup per room

Master Seed

At sign-in, your wallet signs a one-time message. The signature is hashed (SHA-256) to create a master seed stored as a non-extractable CryptoKey in IndexedDB — safe from XSS.

Per-Room Keys

Each room derives its own ECDH P-256 key pair via HKDF(masterSeed, roomHash). This happens locally and silently — no wallet popup needed.

Wallet Signature └─ SHA-256 → Master Seed (IndexedDB, non-extractable) ├─ HKDF(seed, "room-alpha") → ECDH Key Pair₁ ├─ HKDF(seed, "room-beta") → ECDH Key Pair₂ └─ HKDF(seed, "room-N") → ECDH Key PairN
04

1:1 Chat — Double Ratchet

Signal-level protocol for private conversations

X3DH Handshake

Both sides combine their identity key and a fresh ephemeral key via triple Diffie-Hellman to compute a shared root key. Neither the server nor any eavesdropper can derive this.

DH Ratchet — Post-Compromise Security

Every time the conversation direction changes, a new ephemeral ECDH key pair is generated. This creates a fresh shared secret, 'healing' the session even if a previous key was compromised.

Symmetric Ratchet — Forward Secrecy

Between direction changes, each message derives a unique key from an HMAC chain. After deriving the next key, the old one is permanently deleted. Past messages stay safe even if a current key leaks.

Forward Secrecy Post-Compromise Security Unique Key Per Message
RootKey ├─ DH(Alice₁, Bob₀) → RootKey₁ + SendChain_A │ ├─ MsgKey₁ Alice → Bob │ └─ MsgKey₂ Alice → Bob │ ├─ DH(Bob₁, Alice₁) → RootKey₂ + SendChain_B │ └─ MsgKey₃ Bob → Alice │ └─ DH(Alice₂, Bob₁) → RootKey₃ + SendChain_A └─ MsgKey₄ Alice → Bob Each DH step = new ephemeral keys = session heals Each MsgKey = derived then deleted = can't go back
05

Group Chat — Sender Keys

Efficient group encryption with per-member chains

Per-Member Chain

Each member generates their own chain key. When sending, they ratchet forward to derive a unique MessageKey. All other members hold a copy and ratchet in sync.

Secure Distribution

Chain keys are distributed via ECDH-encrypted pairwise channels. Each member computes a shared secret with every peer to securely deliver their key. The server only sees encrypted blobs.

Re-Key on Leave

When a member leaves, all remaining members generate new chain keys. The departed member cannot read any future messages.

Forward Secrecy Post-Compromise Security Unique Key Per Message
Alice's Chain: CK₀ → CK₁ → CK₂ → CK₃ → ... ↓ ↓ ↓ ↓ MK₁ MK₂ MK₃ MK₄ Bob's Chain: CK₀ → CK₁ → CK₂ → ... ↓ ↓ ↓ MK₁ MK₂ MK₃ Each member = own chain Each message = unique key, old key deleted
06

Ephemeral by Design

No logs, no history, no trace

In-Memory Only

Decrypted messages exist only in browser memory. Never written to disk, localStorage, or any database.

Session-Scoped

Close the tab or refresh — all messages and encryption keys are gone. No history to leak.

Server Is Blind

The WebSocket server relays encrypted blobs. It has no plaintext, no stored keys, and no ability to decrypt.

Forward Secrecy

Even if a key is compromised, only the single message encrypted with that specific key is exposed. All others remain safe.

07

Cryptographic Primitives

Standards-based, browser-native

Key Pair DerivationECDH P-256 (from Ethereum signature)
Key AgreementECDH (Elliptic Curve Diffie-Hellman)
Message EncryptionAES-256-GCM (authenticated)
KDF ChainHMAC-SHA256
Initial HandshakeX3DH (Extended Triple Diffie-Hellman)
RuntimeWeb Crypto API (native, no external libs)