What the August 2006 notice said
In August 2006 the ScatterChat project admitted that its documentation overstated one security property. The security researcher Steven Murdoch had shown that the client did not offer “perfect forward secrecy” in the strict sense of the term.
The documentation had claimed that the protocol kept past conversations private only if one peer’s long-term key was compromised. The front page promised “resiliency against partial compromise,” and section 7 of the user’s guide said the same. Murdoch pointed out that this does not meet the strict definition of perfect forward secrecy, which requires past sessions to stay private even if both peers’ long-term keys are compromised. The project said it would revise its documentation to remove the term.
Murdoch wrote up his findings on Light Blue Touchpaper, the blog of the University of Cambridge security group, under the title “Protocol design is hard: Flaws in ScatterChat.” He wrote that the protocol appeared to resist the compromise of one party’s key, because of the way it combined key material with XOR, but not of both. In his view, the root problem was a misunderstanding of what “perfect forward secrecy” means.
Password-protected keys: what the notice argued
The notice also pointed out that ScatterChat encrypted the key files it generated with a password. In theory, an adversary who stole both key files would still need good passwords or passphrases to recover the long-term keys.
The notice then described the obvious limit. Some adversaries can get passwords through out-of-band methods. It named the Chinese government as an example and gave torture as one method. That point still holds in 2026. A password on a key file protects against someone who steals the file. It does not protect against someone who can force the owner to unlock it, or who has malware on the device.
Forward secrecy exists to cover exactly that case. If session keys are short-lived and deleted after use, a later seizure of the device or the long-term keys does not expose old messages, however the attacker got in.
The “not vulnerable” claim, and what came next
The notice said that ScatterChat v1.0.1 was “not vulnerable” to any design or implementation flaw and stayed “safe to use as intended.” The public record shows otherwise. Within weeks the project published two security advisories against that same version:
| Advisory | Date | CVE | What it covered | Rated impact |
|---|---|---|---|---|
| ScatterChat Advisory 2006-01 | August 11, 2006 | CVE-2006-4021 | A birthday attack on the custom padding used with ECB-mode encryption in the IM component. Over large numbers of messages, this let an attacker spot repeated patterns. File transfer used CTR mode and was not affected. | Low (CVSS v2 base score 2.6) |
| ScatterChat Advisory 2006-02 | September 2, 2006 | CVE-2006-4508 | Flaws in the Tor client bundled with the Windows installer. A Tor entry node could route traffic through the client, or crash the Tor process with malformed input. | Low |
The CVE entries list ScatterChat up to and including version 1.0.1 as affected. Murdoch’s own summary said the protocol flaws were “not critical” but did introduce a vulnerability within certain threat models. That fits the record: none of these flaws broke the encryption outright, but together they show why a homemade protocol needs outside review before people at risk depend on it.
The promised version 2.0
The notice said that documentation was “coming soon” for the protocol in ScatterChat v2.0, which would add perfect forward secrecy using the elliptic curve Diffie-Hellman algorithm. That plan is now history. The 2.0 protocol never became a maintained product, and the project has not been maintained for well over a decade.
The technique itself was the right choice. Elliptic curve Diffie-Hellman with short-lived (ephemeral) keys is the basis of forward secrecy in today’s leading messengers. Signal’s Double Ratchet, which WhatsApp also uses for end-to-end encryption, runs a new Diffie-Hellman exchange as the conversation goes on. This gives forward secrecy, and it also lets a session recover if keys are later exposed. Signal added post-quantum protection to the initial key agreement with PQXDH in 2023. On October 2, 2025, it announced SPQR, a “sparse post-quantum ratchet” built on the NIST-standardized ML-KEM 768. SPQR runs alongside the Double Ratchet in what Signal calls the Triple Ratchet.
The notice was signed “JST Duce, Project Maintainer” and dated August 5, 2006.
What to use today instead of ScatterChat
ScatterChat aimed to do two things: encrypt message content end to end, and use Tor to hide who was talking to whom. Today those two needs are usually met by different tools.
| Tool | Content encryption | Metadata protection | Phone number needed | Open source | Independent review |
|---|---|---|---|---|---|
| Signal | End-to-end by default (Signal Protocol, Double Ratchet, PQXDH, SPQR) | Limited: the server still sees that you connect, and when | Yes for sign-up (usernames can hide it from contacts) | Yes | Formal analyses of the protocol published; SPQR formally analyzed by Cryspen |
| Briar | End-to-end | Strong: peer-to-peer over Tor onion services, with no central server | No | Yes | Cure53 audit, March 2017; the issues found were fixed |
| Cwtch | End-to-end | Strong: built on Tor onion services | No | Yes | No completed external audit published as of this writing |
| Ricochet Refresh | End-to-end via Tor onion services | Strong | No | Yes | The original Ricochet had an NCC Group audit in February 2016; Refresh is a later fork on v3 onion addresses |
For most people, Signal is the practical default: content is end-to-end encrypted with forward secrecy, and the protocol is the most heavily studied in consumer messaging. If the threat is someone mapping your contacts, such as a state watching activists, Briar’s design over Tor is closer to what ScatterChat set out to do. The cost is convenience, because both people usually need to be online at the same time.
None of these tools protects a phone that has been seized and unlocked, or that is running spyware. And none of them makes anyone fully anonymous. The EFF’s Surveillance Self-Defense guides make the same point: end-to-end encryption protects what you say, not the fact that you are communicating.
FAQ
Is ScatterChat still safe to use?
No. ScatterChat has had no security updates since 2006. Version 1.0.1 and earlier carry two published vulnerabilities, CVE-2006-4021 and CVE-2006-4508. The Tor client it bundled is also nearly two decades out of date, so even the anonymity layer cannot be trusted.
What is perfect forward secrecy, in plain terms?
It means that stealing someone’s long-term keys later does not unlock their past conversations. Each session or message uses short-lived keys that are deleted after use. Murdoch’s point was that ScatterChat only survived the theft of one side’s keys, while true forward secrecy has to survive the theft of both.
Who made ScatterChat?
Hacktivismo made it. This was an international group of hackers, human rights workers, lawyers and security experts linked to the Cult of the Dead Cow, and it released ScatterChat in July 2006. The client was a “friendly fork” of the Gaim instant messenger (now Pidgin). It added encrypted chat, key management, encrypted file transfer and optional routing over Tor.
Does Signal have forward secrecy?
Yes. Signal’s Double Ratchet derives new keys as the conversation goes on, which gives forward secrecy and also helps a session recover after a key is exposed. Since October 2025 it has also mixed in a post-quantum ratchet, SPQR, built on ML-KEM 768.
Does end-to-end encryption hide who I am talking to?
Not on its own. Encryption protects the content of messages, but the service or the network can still see metadata such as who connects, when and how often. Tools that route traffic through Tor onion services, such as Briar, are designed to reduce that exposure. No tool removes it completely.
What is the lesson of the ScatterChat episode?
Designing a cryptographic protocol is hard, and the right terms matter. ScatterChat’s custom protocol had flaws that outside researchers found within weeks of release. That is why tools that are widely reviewed, openly documented and actively maintained are the safer choice for people who face real risk.
Sources
- Protocol design is hard: Flaws in ScatterChat (Light Blue Touchpaper)
- CVE-2006-4021 (NIST National Vulnerability Database)
- CVE-2006-4508 (Debian Security Tracker)
- ScatterChat Advisory 2006-01 (Bugtraq archive)
- Hacktivismo releases secure IM for activists and dissidents (CSO Online)
- Signal Protocol and Post-Quantum Ratchets (Signal)
- Communicating With Others (EFF Surveillance Self-Defense)
- Why Metadata Matters (EFF Surveillance Self-Defense)
- Messaging applications with Onion Service support (Tor Project)
- Briar security audit (Open Technology Fund)
- Ricochet Security Assessment Public Report (NCC Group)