Security at WillSignal

Every WillSignal message uses one of two modes: Standard or Locked. The promises they make are materially different.

Security claims are easy to exaggerate. This page takes the opposite approach. It explains exactly what each mode protects, which keys provide that protection, and where each promise ends.

Standard messages: protected from outsiders, readable by the service

Standard is the default mode.

A Standard message’s words are encrypted while travelling to WillSignal and remain encrypted while stored. Its title is not: Standard titles are kept in the clear so the service can list them. Either way, the key that opens the words is wrapped using the service’s own key-management system, which means WillSignal can recover that key.

This protects your words from the outside world, but not from WillSignal itself. The service can read a Standard message. That is also what allows the message to be delivered without requiring anything additional from you or your receiver.

Standard is not end-to-end encrypted, and we do not describe it as such.

Choosing Standard means accepting a trade: WillSignal can read the message, and in return, neither you nor your receiver needs to provide a passphrase for the words to arrive.

Locked messages: end-to-end encrypted

A Locked message, including both its title and body, is encrypted on your device before either leaves it. The title is sealed here too — that is one of the concrete differences between the two modes. It can be opened only on a receiver’s device.

Locking a message needs only public keys, so writing one never asks for your inbox passphrase. Opening one does: the receiver needs theirs, and you need yours to reopen or edit your own copy.

What reaches WillSignal is a sealed envelope that the service cannot open. Nothing on the way there carries the plaintext, the raw content key, or any passphrase. Locked words can still reach us afterwards if a receiver reports the message — that case is set out among the limits below.

The cryptography is deliberately standard and unexotic, using libsodium throughout:

XChaCha20-Poly1305 encrypts the message content.
X25519 sealed boxes hand the content key to each receiver.
XSalsa20-Poly1305 wraps your own private key under your passphrase.
Argon2id turns the passphrase into a key and is deliberately tuned to make guessing expensive.

A receiver needs both a WillSignal account and an inbox passphrase to read a Locked message.

An email address without an account behind it cannot yet receive a Locked copy. The compose flow tells you when this happens. You can keep the message Locked and leave that person out for now, or switch the message to Standard so they can be included.

The keys behind it

When you create your account, you choose an inbox passphrase and receive a recovery code.

Your mailbox key is generated on your device. Its private half is then wrapped on that device twice: once under the passphrase and once under the recovery code. Only those wrapped copies reach WillSignal.

The passphrase and recovery code themselves never do.

This design determines exactly what happens when something is lost:

Forgotten passphrase: Your recovery code restores access to the same mailbox key and lets you set a new passphrase. It does not recover the old passphrase. The underlying key remains unchanged, so nothing becomes unreadable.
Both secrets lost: The old mailbox key becomes unrecoverable. There is no override or master key. Any override available to you would also be available to an attacker.

When both secrets are lost, your mailbox starts again with a newly generated key.

Locked messages sealed to the old key remain unreadable until each sender explicitly chooses to reseal them to the new one. That needs a sender who can still sign in and act, so messages from someone whose signal has already gone out are unlikely ever to be resealed and may be lost for good. Locked messages you previously sent may also become unreadable to you.

Resealing is always an explicit act by someone. A changed key never silently receives access to existing Locked content. A stale seal fails closed every time.

The limits, stated plainly

Locked controls who can read, not who wrote.
Encryption decides who can open your words. It does not prove who sent them: the name on a message comes from your account, not from the cryptography.
We supply the key your device seals to.
Your device asks WillSignal for the receiver’s public key and trusts the answer; there is no fingerprint to compare it against today. WillSignal also ships the app that does the encrypting. So “WillSignal cannot read Locked content” holds as far as three things do: the key we hand your device is genuine, the app you are running is genuine, and your own device is uncompromised.
Metadata is not sealed.
Even when a message is Locked, WillSignal can still see the shape of the activity around it: who you designated, when you did so, and how many receivers there are.

The title and words are sealed. The outline around them is not.
A delivered message belongs to its reader.
Once someone has opened your words, pulling the message back removes it from their inbox. It cannot remove the words from their memory or from any copy they kept.
A reported message reaches us in the clear.
If someone you sent a Locked message to reports it, their app sends us the title and text their device has already decrypted, so a person can review it. Only a receiver can do this, and only for a message already delivered to them. The copy is deleted 30 days after the report is closed, unless it is being kept as evidence.

Two passwords, on purpose

WillSignal deliberately separates signing in from unlocking encrypted content.

Your sign-in takes place through a hosted sign-in page. It may use a password managed by that page or an account from Google, Kakao, or Apple. WillSignal’s own screens never request or see your sign-in credential.
Your inbox passphrase is entered only on your device and only when content must be locked or unlocked. It is separate from your sign-in password, and WillSignal never receives it.

The recovery code belongs to the inbox passphrase side only: it restores access to your mailbox key. It has nothing to do with signing in.

Boundaries beyond encryption

Not every WillSignal security boundary depends on cryptography. Some depend on refusing to release information outside its intended context.

Message content is released only inside WillSignal. It never travels through email or text message in either mode. An email from WillSignal never contains your words.
A receiving address is shown only to someone who already knows it: either someone who entered that exact address or the person who owns it. Address lookups are rate-limited and logged. They exist to clarify who you are addressing, not to create a searchable people directory.
Until your signal goes out, receivers can see only a count of waiting messages. The way messages remain sealed before delivery is explained on the How it works page.

Where this stands

We have repeatedly reviewed WillSignal’s design and implementation for security weaknesses throughout development.

WillSignal has not yet undergone an independent third-party security audit.