Security, audit method · Crypto Enterprise Skip to content

Security

An audit where half the work was proving us wrong.

Auditing means one simple thing: reading through all the code looking for ways to break it, the way someone who wants to harm you would. We did that across the whole product, in house, under one rule. Every suspected flaw is handed to a second analysis whose job is to show that it does not exist. What survives gets fixed, then watched by an automated test.

181

issues examined

Three successive rounds: a general review in July, then an offensive review and a manual review of the cryptographic core in early August.

63

false alarms ruled out

On closer inspection, the danger they described did not exist. An audit that rules nothing out is an audit that did not look. The latest round rejected one for quoting code that did not match the file, the commonest defect of a hurried review.

118

real flaws confirmed

34 are fixed, each with an automated test that replays the attack to check that it now fails. The rest are still open, including one rated critical. We would rather write that down than leave it out.

The method, step by step

  1. Step 1: attack

    We read through the whole codebase hunting for flaws. Every questionable behaviour is written down, along with the attack it would make possible.

  2. Step 2: contradict

    Each issue then goes to a second analysis whose job is to show that it is wrong. 30 of the 72 did not survive that step. That is why we can say the numbers on this page are not inflated.

  3. Step 3: fix and replay

    Of the 118 confirmed flaws, 34 are fixed. Each fix ships with a test that replays the attack every time a new version is built: if the flaw ever returns, the build stops before that version reaches your device. The rest are not fixed yet: sometimes the fix depends on wider work, sometimes it changes the format of messages on the network and would break compatibility between versions, which has to be designed rather than improvised. The flaw-by-flaw detail is not published today, and we will not pretend otherwise until it is. Write to us and we will answer precisely on the ones that bear on your use.

What the latest round found

In early August two further rounds targeted the cryptographic core. Two flaws were demonstrated by a program that runs them, not merely described.

The first is fixed. A key-exchange defect let someone holding no key at all get a conversation accepted. The missing check already existed elsewhere in our own code; it was absent precisely where every conversation passes. Fixed, with a test that replays the attack on every build.

The second is not, and it is rated critical. Two colluding relays can mark a message on the way in and recognise it on the way out, which links sender to recipient. Fixing it changes the format of messages on the network: that has to be designed, not improvised. The current network has a single operator, so nobody can exploit it today, but it must be settled before relays run by other people join.

We write this here because a security product that publishes only its successes teaches nobody anything.

Default posture

[profile.release]
panic = "abort"

This configuration line tells the software to stop dead the moment it meets a situation it cannot handle, rather than carry on in an uncertain state. The consequence is deliberate: any crash a stranger can trigger counts as a flaw to fix, never as an incident to wave away.

These numbers come from an internal audit, run by the team that writes the software and not by an independent outside firm. So they are not a certification. They are still checkable: the tests that replay each attack are published in the public repository, next to the code they watch, and anyone can read them or run them again. We claim no label we do not hold. The day an independent body grants us one, its name and the date will be written here.

Report a vulnerability

If you find a flaw, write to us privately before going public. We fix it first, then the flaw and its fix are published. That is what coordinated disclosure means. Your report is read by the engineers who write the code, not by a support desk.

Security contact

crypto.app.organisation@proton.me

Email encryption (PGP) on request · a person replies

Public history of fixes