End-to-end encryption, explained for humans

“End-to-end encrypted” means only the two ends - your device and your contact’s - can read a message. Everything in between sees ciphertext. PrivaMesh takes that further: because there is no server in between at all, the only ends that exist are the two of you. Three well-understood pieces of cryptography make it work.

X3DH - agreeing on a secret without meeting

Before two people can encrypt to each other, they need a shared secret. The X3DH (Extended Triple Diffie-Hellman) handshake, built on Curve25519, lets your devices agree on one even when one of you is offline. It combines several key exchanges so that a first message can be sent immediately and securely. PrivaMesh publishes the needed prekeys as signed prekey bundles, so there is no trusted key server that could hand out a fake key - the signature proves the key belongs to the right account. That is the anti-MITM foundation of the whole system.

Double Ratchet - a new key for every message

Once a shared secret exists, the Double Ratchet takes over. Using HKDF and HMAC-SHA256, it derives a brand-new key for every single message and throws the old one away. Two ratchets turn together: one advances with each message, the other with each reply, mixing in fresh key material. This gives you two powerful guarantees:

• Forward secrecy - if a key leaks today, yesterday’s messages stay locked, because those keys no longer exist.
• Post-compromise security - if an attacker briefly gets in, the ratchet heals with the next exchange and locks them back out.

Post-quantum: X-Wing on iOS 26

Anything written to a public ledger stays there, which turns harvest now, decrypt later into a real threat model rather than a talking point: an adversary can record ciphertext today and wait for a quantum computer. On iOS 26 the handshake mixes X-Wing into the root key - a hybrid that combines ML-KEM-768 with X25519 - so recovering a session means breaking the post-quantum KEM and the elliptic curve, not either one.

It is a hybrid on purpose. A pure post-quantum scheme would stake everything on cryptography with far less deployment history than X25519; combining the two means a weakness in either leaves the session standing. Older devices keep the classical handshake and the two interoperate, with the sender falling back automatically when the recipient publishes no post-quantum prekey.

Padding buckets, and why they stop at 512 bytes

Ciphertext length leaks meaning, so plaintext is padded into fixed buckets - 32, 64, 128, 256 or 512 bytes - before encryption. An observer counting bytes learns which bucket you used, never what you wrote.

The 512-byte ceiling is not a design preference. A larger bucket would produce a memo that exceeds Solana’s 1232-byte transaction limit, so the transport sets the maximum rather than the privacy model.

Paying without becoming identifiable

Metered messaging creates its own privacy problem: proving you paid usually means attaching a receipt to every request, at which point the operator can link your purchase to your activity. PrivaMesh proves the subscription once and receives a pool of RSA blind signatures. Each send spends one token.

The relay can check that a token is valid and unspent, and cannot link it to the purchase or to any other token. Because the tokens are anonymous by construction they are not tied to an account at all - losing the pool costs a re-issue and nothing else. This is the part a messenger would usually skip, and it is what decides whether “we don’t track you” is architecture or marketing.

AES-256-GCM - sealing the payload

The per-message key from the ratchet is used with AES-256-GCM, an authenticated encryption scheme, to seal the actual content. GCM doesn’t just hide the message - it also detects tampering, so a modified ciphertext is rejected rather than silently decrypted wrong. Before encryption, PrivaMesh pads every message to a fixed size, so an observer can’t infer anything from length. A one-word reply and a long paragraph look identical on the wire.

Where the keys live

All of this depends on keys that only you hold. PrivaMesh stores them in the iOS Keychain - device-only and protected by Face ID or Touch ID. They never sync, never upload, and never touch a server, because there isn’t one.

The honest trade-off

Forward secrecy has a real cost: deleted keys can’t decrypt old messages, so your chat history cannot be restored from your account phrase alone. Your phrase brings back your identity, not your conversations. That’s the price of true forward secrecy, and we think it’s the right default for a privacy-first messenger.