Privacy & security

Privacy and security

Keylane makes specific, bounded claims about what it protects. This section explains each one, where the protection comes from, and where it stops.

Security in a messenger is not one property. It is a stack of separate guarantees, each with its own assumptions, and each capable of failing independently of the others. A messenger can have flawless transport encryption and still leak everything through metadata, or hold no server-side data at all and still expose your conversations through an unlocked phone.

Rather than compress that into a single claim, we document it in four parts.

Client security

Where private keys live on your device, how the local message store is protected, and which platform features Keylane relies on.

Server security

What the relay stores, what it cannot see, how long anything survives, and what a full server compromise would actually yield.

Threat model

The adversaries Keylane is designed to resist, and the ones it is not. Read this before deciding whether Keylane fits your situation.

Cryptography whitepaper

The protocol specification: identity, authentication, key exchange, payload encryption, routing, attachments, and push.

The short version

If you read nothing else in this section:

  • Message content is encrypted on the sending device and decrypted on the receiving device. The relay never holds the keys.
  • Identity is a key pair generated locally. There is no phone number, no email address, and no account record tying you to a person.
  • Metadata is minimized, not merely encrypted. The spooling database does not record message senders, so a database dump does not reveal who talks to whom.
  • Retention is bounded. Undelivered envelopes are purged on delivery acknowledgement or after 14 days, whichever comes first.
  • Key exchange is hybrid post-quantum: classical X25519 alongside ML-KEM, so recorded traffic is not decryptable by breaking either one alone.
  • On the device, your PIN is the key rather than a prompt. Locking Keylane destroys the hardware key that protects the keys in memory, so a locked app cannot read its own storage — see client security.

And the limits

Keylane does not protect against an adversary who controls your unlocked device, and it does not hide the fact that you are using Keylane from a network observer who can see your connection to the relay. It cannot recover your identity if you lose every device holding your keys, because it does not hold them either.

Those are design consequences, not oversights, and the threat model covers them properly.

Reporting a problem

Found something wrong in this documentation, or a vulnerability in the product? Security issues go to our disclosure page; everything else to support.

Related policies

The engineering documentation above describes how the system behaves. The legal documents describe what we commit to: