Schneier on Security

Wouldnt possession of this software automatically make you a "bad guy" in China?

Couldnt they use an acronym that did not already stand for "Teletype Over Radio"?

Seems it is very similar to Off the Record Messaging except it uses Tor also. Although I think OTR offers better crypto
http://www.cypherpunks.ca/otr/

@bob

Let me know when you find a three letter acronym that has never been used before.

Webmaster, there's a botched anchor tag in Bruce's posting, that causes the link to extend too far.

The error is after "press release", where there's .lt.a.gt., but needs to be .lt/a,gt.

Link fixed. Thank you.

I think the use of TOR would draw attention to you in places like China.

@saturn

We are running out of TLAs so we need to start switching to FLAs

@bob:  Possession of software that resists surveillance surely makes you a "bad guy" in the USA too, nowadays.

The problem with all of these sorts of things is that if there's a security hole, and there almost always is, it's often possible to use it to look back at the logs from earlier releases and decrypt them. One of the major disadvantages of being an early adopter, that. Hopefully, this client won't try to add new features, and thereby new holes.

I saw this a few days ago (on /., IIRC), and thought the same thing as nash... the exception being that I already use Gaim + OTR + Tor. There's a Gaim + Tor howto @ http://gentoo-wiki.com/HOWTO_Anonymity_with_Tor_and_Privoxy#How_to_use_Gaim_with_tor and OTR doesn't have any problem operating on top of it.

I don't have a problem with re-inventing the wheel, but it's a bit silly if it offers no substantive gain.

I have grave doubts about the crypto used here. Check out their spec at http://scatterchat.com/docs/crypto_protocol.txt .

First, where you or I might use CBC to solve the weaknesses in ECB, their code "[i]nserts a random byte for every three bytes of data, then appends random bytes until resulting block is aligned to 32 bytes." Their use of HMAC seems similarly ideosyncratic.

Second, they claim perfect forward secrecy, but it's clear that they don't get it. From the same URL, they claim that their PFS comes from XOR-ing a secret A from Alice and a secret B from Bob to generate a key. But A and B are both sent under public key encryption: an attacker who compromises the public keys can indeed learn A XOR B and decrypt the traffic, which is precisely what PFS says they shouldn't be able to do.

Don't hold me to this, but I believe that OTR does NOT encrypt file-transfers (not 100% sure, but pretty close), while ScatterChat does. I just wish that this was implemented as a plugin rather than a separate Gaim fork, though I guess they had there reasons for doing so.

I can verify what Nrac says: their perfect forward secrecy ISN'T. Also, they gave a presentation at HOPE on "cryptographic protocol design", which was basically demolished on the spot by someone who I think might have been an OTR developer. I would look very closely at their end-to-end protocol before trusting this app.

That goes double given Evan's point that you can ALREADY use TOR with OTR, so ScatterChat buys nothing.

Also, this may be my bias showing, but that fact that ScatterChat is written by the Cult of the Dead Cow just doesn't incline me to trust it.

Also, their PR could use some work. The first sentence of their website begins "Scatterchat is a HACTIVIST WEAPON..." Compare with the OTR website's "Off-the-Record (OTR) Messaging allows you to have private conversations over instant messaging..." or the Tor website's "Tor is a toolset for... organizations and people... to improve their safety and security on the Internet."

Systems that try to provide anonymity need to try to appeal to a broad audience, since more users means more anonymity. (That is, an anonymity network hides each user among all the other users. If there aren't many users, the adversary has a small number of suspects.) But I bet the average unsophisticated user would be a lot more comfortable using a tool for "private conversations," "safety," and "security" than they would be using a "HACTIVIST WEAPON."

Also, a "HACTIVIST WEAPON" does not sound like something whose presence on your HD you'd like to try to explain to the unsophisticated or unsympathetic. I admit, though, it does sound much cooler than "privacy tool."

Greetings, all! I am the project maintainer of ScatterChat.

Regarding OTR: I believe it is an excellent alternative. SC pre-dates OTR by more than two years, though it was kept internally until recently. That's why SC uses its own protocol. And as the FAQ says, our two projects may be collaborating in the future, so it isn't right to think of us as competitors.

@ Evan: as far as Gaim + OTR + Tor goes, yes, it is possible to mimic SC's anonymous & secure mode already, but who is doing this besides technical users? Techies are not SC's primary audience, therefore integrated support IS unique. Show me a field researcher in Amnesty International who naturally does this.

@ Not really a cryptographer: Yes the perfect forward secrecy really works. I'll gladly discuss it over e-mail with you.

I was hoping that nobody would notice the weird padding that you just pointed out. =] Here's what happened: a year ago I realized that using AES CTR mode with one key doesn't work for asynchronous message transfer (duh!). If each peer sends a message simultaneously to the other, the blocks are decrypted incorrectly. As a temporary solution, I switched to ECB mode and added in more padding. Although I strongly believe that this method is secure, I personally would have liked to release v2.0 to the public instead, which re-introduced AES CTR mode, and brings with it some elliptic curve cryptography (!!). Sadly, v2.0 didn't make it out of the release-candidate phase quick enough to be released at HOPE. And so here we are...

@ Matter: you are correct. SC allows encrypted file transfers because it is a fork. Gaim's API does not currently allow for the necessary file transfer manipulation, so only SC can do this through changes outside of the API structure. The FAQ gives more reasons why SC isn't a plugin.

@ Glenn: yes, the PFS works; e-mail me. And my presentation was *light-years* away from being "demolished." An OTR supporter grilled me on some low-level OTR questions, which I readily admitted I was not brushed up on. If my presentation was instead titled "Low-Level Details of OTR," then yes, I would have been demolished. That OTR supporter was adamant in discrediting me during the Q&A session because of the misperception that SC is strictly an OTR competitor. And it is interesting to note that he later apologized to me.

Thanks for posting about this, Bruce! And by the way, here's a picture of us from when you visited RIT in April: http://www.securitypunk.com/images/Me_Bruce.jpg

Rock on.

Snookums: "it's often possible to use it to look back at the logs from earlier releases and decrypt them. One"

ScatterChat does not log when there is a secure session, so there is nothing to go back and decrypt

@arl: shouldnt that be FLACs?

@bob: actually, that should be ETLA (Extended TLA).

@Glenn Willen:

"Also, this may be my bias showing, but that fact that ScatterChat is written by the Cult of the Dead Cow just doesn't incline me to trust it"

Agreed

Am I the only one here who remembers reading their old text files in ASCII format with little ASCII art cow heads?

You can also use SILC ( http://silcnet.org ) and route it over tor using tsocks.

Just install silc and tsocks, then run the command:

/usr/bin/tsocks /usr/local/silc/bin/silc

@Murgatroyd: TLAv2?

@bob: Too many letters. Maybe TLA2 or TLA+? Both TLA++ and ++TLA, although perhaps esthetically pleasing, are also too long, unfortunately.

See http://www.scatterchat.com/pfs_note.htmlhttp://www.scatterchat.com/pfs_note.html

It appears that the people who believed ScatterChat didn't do PFS were right, and that the authors didn't actually understand the correct definition of PFS.

The response seems to be "Ah well. Who needs PFS? What we do is good enough."

I'm no cryptographer so I can't really discuss different algorithms with you.

I do however believe that the Hacktivismo branch of the CDC do good and it's unfair to critique them for trying.

Their target is to make this end-to-end encryption easy, simplistic enough for your regular 17-year old MSN user or whomever. So that the ease of use can come into effect under political oppression.

Congratulations guys, for putting out another promising bit of software. Hope to see it improve quickly.

Jon Pritchard wrote:
"I do however believe that the Hacktivismo branch of the CDC do good and it's unfair to critique them for trying."

I don't think anybody is criticizing them for trying, but rather for making up a flawed protocol. They may do good in general, but good intentions don't make software correct. Implementors owe it to their users to make security software secure before they recommend it for real use, and we owe it to users to evaluate security claims, no matter how much we like the people who make those claims.

Steven J. Murdoch has just posted an evaluation of the security of Scatterchat on Light Blue Touchpaper; it seems that what we've been saying here is more or less accurate. You can read it here:
http://www.lightbluetouchpaper.org/2006/08/11/protocol-design-is-hard-%e2%80%94-flaws-in-scatterchat/

Thanks for the link, ScatterChat looks like it's being developed quite fast. Hopefully the subsequent 2.0 and 3.0 releases will fix these security issues.