ScatterChat was an encrypted instant messaging client that Hacktivismo released in July 2006. It was discontinued long ago, gets no maintenance, and nobody should rely on it today. It tried to give activists end-to-end encrypted chat and file transfer routed over Tor. The note below explains its most criticised design choice, using AES in ECB mode with extra padding. If you need that kind of protection in November 2026, use a maintained tool that has been independently audited. Signal, SimpleX Chat and Briar (which runs over Tor) are the usual choices.
What ScatterChat was
ScatterChat was a free, open-source instant messaging client built on Gaim, the program later renamed Pidgin. J. Salvatore Testa II wrote it under the handle JST Duce, and Hacktivismo released it at the HOPE Number Six conference in New York City around July 22, 2006. Hacktivismo described itself as an international group of hackers, human rights workers, lawyers and security experts.
At launch, the project promised end-to-end encryption, onion routing through Tor, and secure file transfers. It was written for dissidents and human rights workers behind national firewalls. Its own advisories show that the cryptography was assembled by hand, and the ECB decision explained below is the clearest example.
The maintainer’s note on ECB mode (August 5, 2006)
The original note on this page was written by JST Duce, then the project’s maintainer, and dated August 5, 2006. What follows keeps its content, rewritten in the third person and with historical context added.
Several people had pointed out that ScatterChat v1.0 used AES in ECB mode with padding on encrypted messages, which is non-standard. The maintainer preferred to call it “creative“. The note was meant to explain why the choice was made.
Why CTR mode was dropped
In late summer 2005, the developer realised that AES in CTR mode with a single shared key did not work for asynchronous message transfers. When messages were sent and received out of step, the stream became corrupted.
CTR mode turns a block cipher into a keystream, and it has one hard rule: the same counter value must never be used twice under the same key. If two people share one key and both send messages at the same time, their counters drift apart. They either fail to decrypt each other’s messages or, much worse, they reuse keystream. Reused keystream lets an eavesdropper XOR two ciphertexts together and recover information about both plaintexts.
The standard fixes were well known even in 2005:
- Use a separate key for each direction of the conversation.
- Send a unique nonce or counter value openly with every message, so the two sides never have to share counter state.
- Use an authenticated mode, so tampered or out-of-order messages are rejected instead of decrypting into garbage.
The temporary fix: ECB with extra padding
As a temporary solution, the protocol was switched to ECB mode, with extra padding to deal with repeated blocks. In the note, the maintainer wrote: “I am confident that this solution is secure, even though it is creative.”
ECB encrypts each 16-byte block on its own. Identical plaintext blocks therefore give identical ciphertext blocks, which leaks the structure of a message. To break up those repeats, ScatterChat inserted one random byte after every three bytes of plaintext. That added about 33% overhead, and each 16-byte block held 12 bytes of message and 4 random bytes.
What happened next (history)
ScatterChat v2.0 work began in March 2006, with the aim of making the protocol “less creative”. It was not ready in time for HOPE Number Six, so v1.0 shipped with the ECB design. The note promised that documentation for the v2.0 protocol was coming soon. A later advisory said v2.0 would replace the custom cryptography with the well-tested Off-the-Record (OTR) messaging module, but gave no release date. ScatterChat never became a maintained product after that.
How researchers broke the padding scheme
The padding scheme leaked information. The weakness was theoretical for normal chats, and it did not let anyone decrypt messages. Steven Murdoch of the University of Cambridge showed the flaw publicly in August 2006, and ScatterChat published it as Advisory 2006-01. It is tracked as CVE-2006-4021.
The birthday problem in 32 random bits
Four random bytes per block means only 32 bits of randomness. If you send the same 12 bytes of plaintext again and again, the birthday paradox says two ciphertext blocks will probably match after roughly 2^16 blocks, about 65,000. That is far less than the 2^32 blocks a naive reading suggests. Matching blocks tell an eavesdropper that the underlying plaintext was the same.
Murdoch tested this on Light Blue Touchpaper, the Cambridge security group’s blog. Random plaintext produced no collisions. A zero-filled file produced 47, against the 50 his analysis predicted. He concluded that the encryption mode leaked information about the content being encrypted.
What the flaw did and did not affect
| Point | Detail |
|---|---|
| Identifier | CVE-2006-4021, ScatterChat Advisory 2006-01 |
| Severity | CVSS 2.0 base score 2.6 (Low) |
| Component | Instant messages only; file transfer used CTR mode |
| What leaked | Patterns showing repeated plaintext |
| What did not leak | Message contents or, with Tor in use, user identity |
| Practical condition | Very large volumes of messages in one conversation |
| Planned remedy | Move to the OTR encryption module in v2.0 |
The advisory itself argued that v1.0.x remained safe “in the overwhelming majority of cases”. Murdoch’s broader point was summed up in his post’s title: protocol design is hard. A custom scheme that looks fine to its author can fail under measurement.
A second advisory: Tor routing on Windows
In September 2006, Advisory 2006-02 (CVE-2006-4508) reported a separate problem in the Windows build’s Tor client. It covered routing and denial-of-service issues, and version 1.0.2 fixed them. It had nothing to do with the ECB design, but it showed how a bundled, self-maintained copy of Tor could fall behind the real Tor Project’s fixes.
What ECB mode means in 2026
ECB is now a legacy mode for confidentiality. Its one real weakness is the one ScatterChat tried to pad around: any two ciphertext blocks reveal whether their plaintext blocks are equal.
NIST has moved the same way. In 2022 it proposed limiting ECB approval to uses that other NIST standards allow specifically. One example is a challenge-response protocol in SP 800-73-4. In April 2023, NIST decided to revise SP 800-38A, the 2001 recommendation that defines ECB, CBC, CFB, OFB and CTR. A draft revision of SP 800-131A then proposed treating ECB as legacy, while keeping modes such as CBC, GCM and XTS-AES acceptable.
| Approach | Repeated blocks hidden | Integrity built in | Safe with crossing messages | Typical use today |
|---|---|---|---|---|
| ECB (plain) | No | No | Yes | Legacy, special cases only |
| ECB + random padding (ScatterChat v1.0) | Partly, until birthday collisions | No | Yes | None |
| CTR, one shared counter | Yes | No | No, risks keystream reuse | Avoid |
| AEAD with a fresh nonce per message (AES-GCM, ChaCha20-Poly1305) | Yes | Yes | Yes | Standard practice |
| Per-message keys (Double Ratchet) | Yes | Yes, with an AEAD layer | Yes | Signal Protocol and its derivatives |
The real fix for the 2005 problem was never better padding. It was a fresh key or nonce for every message, plus authentication. Modern messengers do exactly that.
What people use instead today
Today the job ScatterChat was built for, private chat for people facing powerful adversaries, is handled by maintained, audited tools.
| Tool | How it protects messages | Audits and review | Notable limit |
|---|---|---|---|
| Signal | Signal Protocol with Double Ratchet; post-quantum SPQR layer announced October 2, 2025, using ML-KEM 768 | Formal analysis of SPQR with Cryspen; long record of academic study | Needs a phone number to register; your device is still a target |
| SimpleX Chat | No user identifiers; messages sent through relay queues | Trail of Bits implementation audit (2022) and cryptographic design review (2024) | Smaller user base; relay operators can see some traffic timing |
| Briar | Peer-to-peer, over Tor or local Wi-Fi and Bluetooth | Cure53 audit, published with the 2017 beta | Android-focused; contacts must be online at the same time |
| Tor Browser and onion services | Onion routing hides who talks to whom from local networks | Maintained by the Tor Project | Does not encrypt the content of what you type into a site |
Signal’s SPQR runs alongside the existing Double Ratchet. Keys from both are combined into one hybrid key, a design Signal calls the “Triple Ratchet”. The goal is to resist “harvest now, decrypt later” attacks by future quantum computers, while keeping forward secrecy and post-compromise security.
None of these tools makes you fully anonymous. The EFF’s Surveillance Self-Defense guide makes the key point: end-to-end encryption protects what you say, not the fact that you are communicating. Metadata, a compromised phone and unverified safety numbers can all expose you.
There is a fair counter-argument. Some activists distrust any app with a central server or a phone number requirement, and that is why Briar and SimpleX exist. The trade-off is a smaller network and less polish. For most people, Signal with verified safety numbers and disappearing messages is the strongest practical default.
FAQ
Is ScatterChat still safe to use?
No. ScatterChat has not been maintained for well over a decade, its v1.0 message encryption had a published weakness (CVE-2006-4021), and it bundled an old Tor client. Any copy still around today would also miss years of fixes in its Gaim base and its dependencies. Use Signal, SimpleX Chat or Briar instead.
Why is AES ECB mode considered insecure?
ECB encrypts each block on its own with the same key, so identical plaintext blocks always give identical ciphertext blocks. That leaks patterns and repeated content. It also provides no integrity, so blocks can be rearranged without being detected unless a separate authentication check is added. NIST has moved to treat ECB as legacy for confidentiality.
Did the ScatterChat flaw let attackers read messages?
No. The advisory and Murdoch’s analysis agreed that the weakness revealed patterns, meaning repeated plaintext, and did not reveal message contents. It needed very large volumes of messages in one conversation to matter. It was still a real design failure, because a sound encryption mode leaks nothing of the kind.
What should ScatterChat have used instead of ECB?
An authenticated mode such as AES-GCM, with a unique nonce sent alongside each message and separate keys for each direction, would have solved the asynchronous problem. The project’s own plan for v2.0 was to adopt OTR, which gave each message fresh key material. Today the Double Ratchet in the Signal Protocol is the common answer.
Was ScatterChat related to the Tor Project?
No. ScatterChat bundled and used Tor to route traffic, but Hacktivismo developed it separately from the Tor Project. That separation mattered: its second advisory (CVE-2006-4508) concerned routing and denial-of-service problems in the Windows Tor client it shipped, which version 1.0.2 fixed.
Who runs scatterchat.com now?
The domain now belongs to an independent privacy guide under new ownership, with no link to Hacktivismo or the original developers. In 2006 and 2007 the address hosted the ScatterChat project itself. Nothing on the site today is an official ScatterChat release, and no installers are offered.
Sources
- CVE-2006-4021, ScatterChat IM encryption weakness (OpenCVE record)
- ScatterChat Advisory 2006-01: Cryptanalytic Attack Vulnerability (CXSecurity archive)
- ScatterChat Advisory 2006-02: Win32 Tor Client Routing and Denial of Service Vulnerabilities (Full Disclosure mailing list archive)
- Steven Murdoch, “Protocol design is hard: Flaws in ScatterChat”, Light Blue Touchpaper, University of Cambridge, August 11, 2006
- Bruce Schneier, “ScatterChat”, Schneier on Security, July 2006
- NIST CSRC, “Decision to Revise NIST SP 800-38A”, April 2023, and the 2022 proposal to revise SP 800-38A
- Signal, “Signal Protocol and Post-Quantum Ratchets” (SPQR), October 2025
- Trail of Bits, SimpleX Chat security assessment, and SimpleX’s v6.1 cryptographic design review announcement, October 2024
- Briar Project, “Beta released, security audit” (Cure53), July 2017
- EFF Surveillance Self-Defense, “Communicating With Others”
- Hacktivismo entry, Wikipedia; InfoWorld and Slashdot launch coverage, July 2006