If the door offered by the platform has a copy of the key for the guard, build your own door. But remember: the guard can demand that all doors they cannot open be torn down.
There is an approach that frequently arises when discussing Chat Control with technically informed people: what if users encrypt their messages with keys they manage themselves, outside the platform's control?
The idea is simple and powerful. Instead of trusting the encryption offered by the platform (which the law could force to be weakened), users agree on a key through an external channel and encrypt the content before the platform touches it.
The scheme
External channel: A —————————[k_AB]——————————→ B
(face-to-face key agreement, Signal, encrypted email, paper)
A writes M
A encrypts M with k_AB → C = E_k_AB(M)
A sends C through the platform
B receives C
B decrypts C with k_AB → M
The platform only sees C (unintelligible data)
In this scheme:
- The platform receives , which from its perspective is noise indistinguishable from random data
- The platform cannot scan the content because mathematically it has no access to
- CSAR cannot force the platform to decrypt what it cannot decrypt
- A and B maintain total control over their communication
What this approach solves
| Problem | Solved | Why |
|---|---|---|
| Content scanning by the platform | Yes | The platform only sees ciphertext |
| Key escrow | Yes | The key never touches the platform |
| Classifier expansion | Yes | There is no classifier to expand |
| Retrospective scanning | Yes | No accessible content to rescan |
| Detection of "user who encrypts" | No | The platform sees high entropy |
| Metadata | No | Who, when, how much, frequencies |
| Legal pressure on endpoints | No | The key is in the hands of A and B |
What it does not solve
1. The high-entropy detection problem
A message encrypted with a robust scheme produces data that is statistically indistinguishable from random noise. A platform that knows the expected format of its messages (e.g., JSON with structured fields) can easily detect that a message does not follow that format:
Normal WhatsApp payload:
{"key": {"remoteJid":"...","fromMe":true},"message":{"conversation":"Hello"}}
Entropy: ~4.2 bits/byte
Externally encrypted payload:
<7e9f2b8a1c4d... (apparently random bytes)
Entropy: ~7.9 bits/byte → detectable
If the law requires the platform to block non-scannable messages, this simple entropy detector would be sufficient to identify and block these messages.
2. The external channel problem
The weakest link in the scheme is the initial key exchange:
How do A and B agree on k_AB without using the platform?
├→ Face to face: Secure, but does not scale
├→ Signal: Secure, but requires both to use Signal
├→ Encrypted email: Feasible, but cumbersome
├→ WhatsApp itself: The platform can intercept it
└→ Paper/QR code: Secure, but impractical for frequent contacts
For the approach to work with non-technical contacts, the key exchange would have to happen through the platform itself, which reintroduces the problem: if the platform can see the key, external encryption is irrelevant.
3. The law that closes the loophole
This is the critical point that pure technical analysis tends to overlook. A law like CSAR is not limited to saying "platforms must scan." It can (and would foreseeably include) provisions such as:
Article X: Providers shall ensure that all messages transmitted
through their infrastructure are susceptible to detection in
accordance with Articles Y-Z. The transmission of content that,
by its format or technical characteristics, prevents the
application of mandatory detection measures is prohibited.
In that scenario, the platform would be obligated to:
- Detect messages with unusually high entropy
- Block their transmission
- Report the user as "suspected of circumvention"
Comparison with other approaches
| Aspect | External encryption | CSS | Key escrow | Report threshold |
|---|---|---|---|---|
| The platform sees the content | No | Yes (before encrypting) | Yes | Only if reports exist |
| Scalable for non-technical users | No | Yes | Yes | Yes |
| Resistant to legal expansion | High | Low | Low | Medium |
| Requires trust in the platform | No | Yes | Yes | Partial |
| Detectable as "circumvention" | Yes | No | No | No |
The critical mass problem
External encryption with shared keys works perfectly as a handcrafted measure for a technical user who:
- Knows how to generate and manage keys
- Has contacts who also know how to do it
- Accepts the friction of the process
But it does not work as a systemic solution for 500 million Europeans. The reason is not technical but structural: a law that requires scanning on the platform will simply prohibit or block traffic that cannot be scanned, and the vast majority of users will have neither the knowledge nor the motivation to adopt an external encryption system.
User pyramid:
▲ ~0.1% Advanced technical users (possible external encryption)
├ ~1% Intermediate technical users (possible with effort)
├ ~10% Aware users (not viable without tools)
▼ ~90% Mainstream users (use what the app offers)
If the law blocks external encryption, ~99.9% of users
will have no protection. And the 0.1% will be detectable as "user who
protects themselves," exactly the same paradox that Obscura documents
in the context of fingerprinting.
Parallel with the protection paradox
This approach suffers from the same asymmetry that Obscura's research documents for anti-fingerprinting:
The defender must win every time. The attacker only needs to win once.
In the context of Chat Control:
- The user needs to protect all their messages in an indistinguishable way
- The platform needs to detect a single anomaly (a message with high entropy, an unusual communication pattern) to identify the user as "suspected of circumvention"
- Once identified, the user can be subject to additional measures (blocking, reporting to authorities, investigation)
The analogy with fingerprinting is almost perfect. In Obscura, the proxy had to normalize all signals to avoid detection; here, the user must make all their messages appear to be normal platform messages, which is incompatible with encrypting them externally.
Conclusion
External encryption with shared keys is technically sound as an individual privacy measure. If A and B agree on a key outside the platform and encrypt their messages, the platform cannot read, scan or report them. Period.
But as a political and systemic solution against a law like CSAR, it has three irresolvable problems:
- The law will close the loophole by prohibiting or blocking non-scannable messages
- Key exchange reintroduces the problem for most users
- The defender-attacker asymmetry makes the user detectable as a "circumventor" even if their content is secure
It is not a wrong approach. It is an approach that works for those who can implement it, but cannot be generalized as an alternative to mass scanning. It is the difference between building a nuclear shelter for your family and expecting all of humanity to live in nuclear shelters.
Related documents:
