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.

72

issues examined

Spotted while reviewing the whole product: the app, the network relays, the server that keeps the list of relays, calls.

30

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.

42

real flaws confirmed

30 are fixed, each with an automated test that replays the attack to check that it now fails. 12 are still open and written down in plain sight, with their reason.

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 42 confirmed flaws, 30 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 other 12 are documented, with the reason they are not fixed yet. Sometimes the fix depends on wider work, sometimes the cure would cost more than the disease.

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 fix tracker