Comparison
Keylane compared with Signal, Matrix, Session and Threema
Comparison pages written by vendors are usually worthless, because the vendor picks the rows. We have included the rows where Keylane loses, because a table you cannot trust is not worth reading.
Compiled 18 August 2026 from public documentation and vendor security whitepapers. Found something out of date or wrong? Tell us and we will correct it.
Signal is the most mature and most thoroughly audited of these, and for most people it is the right default. Keylane is worth considering if you specifically need identity that is not tied to a phone number and the option to run your own federated infrastructure. Those two together are what Keylane exists for — Threema does the first half and has done for years, Matrix the second. On almost everything else, the older projects have a head start we do not pretend to have closed.
Feature comparison
| Keylane | Signal | Matrix | Session | Threema | |
|---|---|---|---|---|---|
| Phone number required | No | Yes | No | No | No |
| Identity model | Device key pair | Phone number | Homeserver account | Random Session ID | Random Threema ID |
| Network architecture | Federated | Centralized | Federated | Decentralized onion network | Centralized, Swiss |
| End-to-end encryption | Always on | Always on | On by default for private rooms | Always on | Always on |
| Post-quantum key exchange | Yes, hybrid | Yes, hybrid | Not standard | No | Announced, not shipped |
| Forward secrecy | Yes | Yes | Yes | No, by design choice | Yes, since Ibex |
| Server stores sender identity | No | No, sealed sender | Yes | No | Yes, routing IDs |
| Server-side history | No, 14-day spool | No | Yes, encrypted room state | No, short TTL | No, dropped on delivery |
| Hides your IP from the server | No | No | No | Yes, onion routed | No |
| Self-hostable server | In development | No | Yes | Service node network | Yes, commercial OnPrem |
| Client fully open source | Core only, full release in preparation | Yes | Yes | Yes | Yes |
| Independent security audit | Not yet | Yes | Yes | Yes | Yes |
| Voice and video calls | Yes | Yes | Yes | Yes | Yes |
| Desktop client | Planned | Yes | Yes | Yes | Yes |
| Maturity | Public beta | Mature | Mature | Mature | Mature |
| Funding model | Self-funded company | Non-profit foundation | Foundation and vendors | Foundation and token | Paid app purchases |
On the phone itself
Comparisons usually stop at the network hop, where all five of these are strong. But the copy of your conversation that lives longest is the one sitting on your own device, and that is the copy a thief, a border officer, or a forensic suite actually gets. What differs enormously is how much of it a seized phone gives up.
Every app here encrypts with a full-entropy random key; none of them derive it from anything you type, and Keylane does not either. So the question that decides the outcome is not the cipher or the key length but what has to happen before that key can be used again. A key the app can unwrap unattended is a key an examiner with the phone can unwrap too. A key wrapped under a secret of yours resists that, and instead becomes as strong as the secret.
| Keylane | Signal | Matrix | Session | Threema | |
|---|---|---|---|---|---|
| Content key itself | Random 256-bit | Random 256-bit | Random | Random 256-bit | Random 256-bit |
| Message content encrypted by the app | Yes, per record and per file | Yes, whole database | Client-dependent | Yes, whole database | Yes, whole database |
| Opening it needs a secret you know | Yes, your PIN unwraps it | No | No | Optional, desktop only | Optional, Android only |
| Where the key rests while the app is closed | Wrapped under your PIN, nowhere else | OS keystore, usable unattended | Keystore, keyring, or browser storage | Keystore on mobile, config file on desktop | Keystore, under your passphrase if set |
| Locked app on a seized phone gives up history | No | Yes, with keystore access | Yes | Yes | Yes, unless a passphrase is set |
| Keys erased from hardware when the app locks | Yes | No lock of that kind | No | No | On restart, if a passphrase is set |
| Copied store attackable offline, without the device | Yes, at PIN entropy | No, wrap key never leaves the phone | Client-dependent | Mobile no, desktop yes | Yes, unless a passphrase is set |
| Readable with no key at all | Timestamps, ordering, contact IDs, ratchet state | Nothing | Client-dependent | Nothing | Nothing |
Two of those rows are a design choice rather than a scoreboard. Encrypting the whole database file, which is what SQLCipher does for Signal and Session, leaves nothing legible without the key — the structure in the last row included. Encrypting record by record, as Keylane does, leaves that structure exposed but means a running app never holds a decrypted archive at all: only what is on screen is in the clear, and the key comes out of hardware one operation at a time, so a live memory capture takes the screen rather than the history. The cipher strength is equivalent either way; the two choices survive different attacks. The reasoning, and what it costs us, in full.
Forensic work splits a seized phone into two states. Before First Unlock — powered off, passcode never entered since boot — is close to a sealed box for every app on this page, ours included. After First Unlock is the phone in your pocket, screen locked, unlocked once since it booted. That is the state phones spend nearly all their time in, and the state almost every real seizure catches them in.
So the fourth row is not one row among eight; it is the one the others are a rehearsal for. An app whose store key can be unwrapped without you present hands over the whole history in that state — which covers Signal, Session, Element, and Threema without its passphrase. Keylane is the one entry that does not, because the key was destroyed when the app locked and the only thing that regenerates it is a PIN that exists in your head. That single row is the reason the app is built the way it is.
The two rows we lose are worth just as much of your attention: a copy of the profile taken away and attacked offline, and the metadata sitting in the clear either way.
- Signal
- On Android the message database is SQLCipher-encrypted, but its key is wrapped by an Android Keystore entry the app can use at any moment, with no PIN or passphrase in front of it. A full-filesystem extraction plus Keystore access reads the whole history; the app’s screen lock gates the interface, not the key. On desktop that key sat in plain text in
config.jsonfor roughly six years, until a change in July 2024 moved it behind Electron’ssafeStorage— DPAPI on Windows, Keychain on macOS, the session keyring on Linux. That stops a different user account on the same machine. It does not stop code running as you, which is the case that matters. - Session
- A Signal fork, so its mobile storage behaves much the same. On desktop it is a step behind: the SQLCipher key is written to
config.jsonin the clear unless you set an application password, and published forensic walkthroughs treat that file as the entire answer. Setting the password is the difference between an encrypted database and a decorative one. - Matrix
- There is no single answer, because Matrix is a protocol with many clients — which is itself the finding. Element Android encrypts its local store under a Keystore-held key; Element Desktop keeps its pickle key in the system keyring; Element Web holds room data and crypto state in IndexedDB, protected by browser-profile boundaries rather than by anything you supply. Assume nothing about a given Matrix client until you have read that client’s own storage documentation.
- Threema
- The only other app here that puts a secret of yours in front of the database. On Android its own AES-256 layer covers messages, media, and the ID private key, and the master key can be wrapped in an optional Master Key Passphrase, re-entered after every restart; Threema states plainly that without one the protection is limited. On iOS it leans on the platform instead — Data Protection keyed to your device passcode, with the ID key in the Keychain. Its in-app PIN lock is a UI gate with no cryptography behind it. Worth noting against our own row above: because that passphrase takes arbitrary characters rather than ten digits, a carefully chosen one resists an offline attack on a copied store better than a Keylane PIN does.
- Keylane
- Records and files are encrypted individually rather than by locking one database, under a random 256-bit key. Your PIN does not become that key; it derives, through 600,000 PBKDF2 iterations, the key that unwraps the profile the storage key sits in. While the app runs, the storage key is instead sealed by a Secure Enclave or Keystore key that is deleted outright the moment Keylane locks, so an image captured after that cannot be opened later, by an examiner or by us. Two honest costs. The shape around the content — timestamps, ordering, unread counts, your contacts’ Keylane IDs, live ratchet state — is stored in the clear. And because the wrap is a PIN rather than a passphrase, digits only and ten at most, an adversary holding a copy of the profile has an offline problem capped near thirty-three bits: trivial at four digits, and a matter of days on rented GPUs even at ten. A random key sealed in a phone’s secure hardware, as Signal uses, has no equivalent offline attack at all. The whole design is written out in client security.
Every app here decrypts your messages in order to show them to you, so an implant running while the app is unlocked reads plaintext regardless of how the keys are stored. On-device encryption answers for the seized, stolen, and imaged phone — not the compromised one.
And Keylane has no desktop client yet, so it sits out the desktop half of this comparison rather than winning it.
Where each one is strongest
Signal
The best-audited encrypted messenger available, run by a non-profit with no commercial incentive to change. Its protocol is the reference the rest of the field is measured against, including ours.
The trade: a phone number is mandatory, and the network is centralized. If your concern is that a number ties your identity to a real person, that is not a problem Signal is trying to solve.
Matrix
The most established federated protocol, with a large ecosystem, mature self-hosting, and bridges into almost every other network. Well suited to organizations that want to own the whole stack.
The trade: homeservers hold substantial room state and metadata, so a compromised server reveals considerably more than a Keylane relay would.
Session
The only one here that hides your IP address from the network by routing through onion nodes. If network-level anonymity is your requirement, this is the one that addresses it directly.
The trade: Session dropped forward secrecy as a deliberate design decision. A future key compromise exposes past messages in a way it would not on the others.
Threema
Phone-number-free identity, shipped years ago, audited, and sold as a paid app rather than funded by anything else. It is also the only other client here that will put a passphrase of yours in front of its local database.
The trade: the network is centralized and Swiss, federation is a commercial on-premises product rather than something an individual runs, and post-quantum key exchange is announced but not yet shipped.
Keylane
Phone-number-free identity combined with federation and a relay that stores no sender records — the specific combination the others each hold one half of. Post-quantum from the first release, and local storage whose key leaves the device’s hardware the moment you lock the app.
The trade: the youngest project here. No completed independent audit, the full client source still in preparation, self-hosting unfinished, and no desktop client yet.
What about WhatsApp, Telegram and Viber?
Those three are where most of the world actually messages, so their absence from the table needs an explanation rather than a silence. They are absent because including them would flatter us. They would lose almost every row, and a table in which the vendor’s own product wins fifteen out of sixteen tells you about the vendor’s choice of rows, not about the products.
There is a category problem too. Telegram’s ordinary chats are not end-to-end encrypted at all, so a cell reading “yes” on the strength of its Secret Chats would mislead more than it informed. What follows is the short, fair version of each instead.
The encryption is not the weak point, and anyone who tells you otherwise is overselling their alternative. Messages and calls are end-to-end encrypted by default, using the same Signal protocol Signal does.
The objections are everything around it. A phone number is mandatory, the client is closed source, and the metadata — who you talk to, when, how often, from which address, in which groups — is exactly the part Meta needs and the part no end-to-end encryption covers. On the device, the message database is encrypted with a key that sits in the app’s own directory for anything with filesystem access to collect, which is the same shape as Signal’s Android storage. End-to-end encrypted cloud backups exist, but they are opt-in; if you never turned them on, the copy in Google Drive or iCloud is not protected from WhatsApp itself.
Telegram
The one where the default genuinely matters. Cloud chats — every group, every channel, and every ordinary one-to-one conversation — are encrypted between you and Telegram’s servers rather than end to end, and Telegram holds those keys.
Its end-to-end mode, Secret Chats, is one-to-one only, does not sync across your devices, and is not available in the desktop client at all, so a good number of people who believe they are using it are not. The underlying MTProto design has never earned the reputation the Signal protocol has. The clients are published source; the server is not. Of everything named on this page, Telegram is the only one whose everyday messages are readable to a compromised or compelled server — which makes it the one case where switching changes whether you have end-to-end encryption, rather than how good it is.
Viber
End-to-end encrypted by default for one-to-one chats, group chats, and calls since 2018, which puts it on the wire in the same category as WhatsApp.
What is missing is everything that would let you verify that. The client is closed source, there is no published independent audit of the implementation to point at, and the local message store on Android has long been an ordinary SQLite database that forensic tools read directly, without the encrypted-store layer every app in the table above has. A phone number is mandatory. It is owned by Rakuten, and it carries advertising.
Which should you use?
Most people should use Signal. It is mature, audited, well funded, and the encryption is excellent. Recommending a beta product to someone who just wants private messaging would be self-serving.
Use Matrix if you are an organization that wants to own its infrastructure today and needs bridges to other networks.
Use Session if hiding your IP address from the network is a hard requirement and you accept the forward-secrecy trade-off.
Use Threema if you want identity without a phone number from something mature and audited today, and you would rather pay for the app than wait for federation or post-quantum.
Use Keylane if you want identity with no phone number attached and a path to running your own federated relay, and you are comfortable using beta software while the audit and the source release land.
These are not exclusive. Installing more than one costs nothing, and the right answer for a threat model that matters is usually not to depend on any single tool.
Check our claims
Every claim made about Keylane in the table above is documented rather than asserted. Start with the threat model, which is where the limits are written down.