Security status and roadmap

Security isn't a box you tick: it's a state that changes. Here we tell you, without embellishment, what protects you today, what we do NOT have yet, and what we're working on. We'd rather you hear it from us.

What protects you today

End-to-end encryption on your device

Available

Plaintext only ever exists on the phones. The sender encrypts with the recipient's public key (ECIES: ECDH over P-256 + AES-GCM, with the AES key derived via HKDF-SHA256 and the ephemeral key bound as AAD) and only the recipient, with their private key, can decrypt. Neither the central server nor the node sees the content.

No phone number

Available

We don't ask for your phone number, so there's no link to your real identity and no surface for SIM-swapping. Your identity is a user code, not a number. To provide the service we do need an email address, but it can be anonymous: even on the free plan you can use LOOKLOCK without revealing who you are.

Your mailbox on your own node

Available

Messages and files (already encrypted) rest on a node you can run yourself. It lowers the value of attacking the central infrastructure and gives you sovereignty over retention and purging.

The private key never leaves the device

Available

The private key is generated and kept on the phone (Android secure storage). It is never uploaded to the server.

Key backup and recovery

Available

You can export your key or email it to yourself (protected by a security question only you know) and restore it on another phone: you recover the SAME identity and can read your messages again. And if a contact loses their key, you can resend them your shared history re-encrypted with their new key. Since it's E2E encryption, losing the key without a backup is irreversible — that's why we insist you back it up.

Key verification between users (anti-MITM)

Available

Since the central server hands out public keys, you need to be able to check that your contact's is the real one. Now you can: in each conversation, a "safety number" you both compute ON THE PHONE from your keys and compare by QR or out loud. It's computed on the device, not on the server, so not even we can fake it; it also warns you if a contact's key changes.

How we protect history: Double Ratchet

Device A starts the session B's prekeys (X3DH) IK · signed SPK · OPK from the central directory Device B publishes its prekeys X3DH → shared secret (SK). Authenticates both. Ratchet: a unique key per message SK K1 message 1 K2 message 2 K3 message 3 K4 message 4 K2 leaked If one key leaks, neither past nor future is decrypted. That's forward secrecy and post-compromise recovery.

Each text message uses a new key derived by the ratchet. It activates between two up-to-date users; if the other doesn't have it, the previous encryption is used automatically.

Current status: Double Ratchet is TEMPORARILY DISABLED while we fix a session-setup issue with newly registered users. Meanwhile, every message stays end-to-end encrypted with an ephemeral key (ECIES v2) and history resilience relies on key backup and recovery. We'll re-enable it after real-device validation.

Known limitations (compared with the best in the field)

Signal is today's cryptographic benchmark. These are the real differences versus it, and what we're doing about each.

Forward secrecy

In progress

Each message uses an ephemeral sender key, but your receiving key is fixed. That means if your private key were leaked, the history of stored envelopes could be decrypted. Signal uses "Double Ratchet" so that can't happen. We're evaluating an equivalent mechanism (ratchet or one-time keys) without breaking the mailbox model.

Metadata: distributed, not eliminated

In progress

Content is encrypted, but the central server knows who exists and which node they're on, and the node sees who deposits/collects and when. It isn't a single server that sees everything, but it isn't "zero metadata" either. We're working on "sealed sender" techniques so the node doesn't know who's sending.

External audit and open source

In progress

We've already published the protocol specification and are opening the client and node code (AGPL-3.0 license) so anyone can review it. An independent audit is still pending. In security, "trust our word" isn't enough.

Post-quantum cryptography

Under evaluation

We don't yet use cryptography resistant to quantum computers. It matters because of "harvest now, decrypt later". We're following the hybrid approach (Kyber-style) that Signal already deploys and have it on the radar.

Platforms: Android only for now

Under evaluation

Today there's only an Android app. iOS and desktop (and multi-device use) are pending. We say so, so nobody buys expectations we don't yet meet.

Our commitment

This page will be updated as we close each point. We don't promise to be Signal tomorrow; we promise to tell the truth about where we are today. If the privacy of your conversations is critical against a well-resourced adversary, right now Signal is more robust and we recommend it without hesitation.

Comparison Architecture Transparency