How Livara encryption, recovery, and sync work

Each device keeps independent P-256 and ML-KEM-768 private identities. A fresh ML-KEM contribution is encapsulated to both participants and combined with P-256 ECDH through HKDF-SHA-256.

Direct text uses AES-256-GCM with an additional HMAC-SHA-256 check. Direct media is encrypted before it reaches storage.

The server still stores routing, membership, timestamps, and ciphertext so connected devices can synchronize.

Livara clients and server require hybrid ML-KEM-768 + P-256 encryption for every newly sent direct message, edit, caption, and attachment.

Group and channel messages are protected in transit with HTTPS/WSS and by server-side membership and role checks, but their content is available to the server.

Livara claims post-quantum hybrid protection only for direct-message content. It does not claim group end-to-end encryption, post-quantum call media, or hidden routing metadata.

The P-256 private key and ML-KEM seed are bundled and sealed on the client with a random 256-bit recovery key, HKDF-SHA-512, and AES-256-GCM before upload. Restoring requires the recovery key; signing in alone is not enough.

Recovery format v5 binds its version and hybrid suite into authenticated data. Existing hybrid v4 backups are accepted and upgraded after a successful restore.

Public-key fingerprints can be compared between participants to detect an unexpected key change.

Losing both the private key and recovery phrase can make existing direct-chat ciphertext unrecoverable.

Socket events keep active conversations responsive without repeatedly polling the whole account.

Each relevant database change also advances a contiguous per-user sequence, so a reconnecting client can request the exact gap.

Clients deduplicate by stable IDs and reconcile authoritative server snapshots before advancing their saved cursor.