[liberationtech] Peer-review required: SwaTwt and TweedleDH

[Daniel Colascione]

Hi Steve,

First off, I don't think SwaTWT is particularly *useful*. Sending an
encrypted message is a solved problem: use PGP or OTR. These systems are
infinitely better than plain old (unauthenticated!) symmetric cryptography.

That said, constructive criticism is better than sternly shooting down a
well-meaning novice; at least he asked for someone to review his work.
If you pin his ears back, you're just teaching him to not ask for input
next time.

On 9/28/2010 6:12 PM, Steve Weis wrote:
> Besides the fact that this is asking users to trust "SwaTwt.com"
> completely

Right.

If someone *insists* on using Twitter as a communications channel, the
program to generate and read the tweets should at least be conventional
client-side applications. This functionality belongs in a Twitter
reader, not on a website.

(OP, you can get something very close to a "zero-install" experience by
just providing a standalone program with few dependencies.)

But like it or not (and I don't) we're moving toward a thin-client
world, and a new generation of programmers will try to create sites like
SwaTWT. It's better to educate them as to why it's a bad idea, dissuade
them if possible, and if not, try to at least make their implementations
safer for users.

The first problem with SwaTWT is that it's not served over SSL. What's
the point of sending cryptography to the client over an unsecured
channel? It's all moot if an attacker can transparently replace SwaTWT's
code with something that sends the plaintext to his own server without
the user's knowledge.

Even with SSL, however, there's no trust advantage to doing the
cryptographic work on the client instead of sending it off to the SwaTWT
server. Sure, in the current implementation, SwaTWT doesn't see the
plaintext. But SwaTWT could change that, and the user would never know
--- so a cautious user must assume that SwaTWT can already see everything.

(Not that the X.509 PKI is particularly secure in the face of
unscrupulous CAs; see [1].)

Now, that level of trust might be acceptable to some people, but it
needs to be made explicit, and it certainly isn't good enough for
anything seriously sensitive.

>, the underlying crypto algorithm is "CipherSaber 2". That
> appears to be a variant of RC4 of dubious origins and quality. Even if
> this were a good algorithm choice, the implementation itself is
> insecure. Here's a hint:

Personally, I think the "CipherSaber" site gives off that familiar
crackpot scent; I don't like to mix my cryptography and my politics.
Furthermore, RC4 has a number of well-known weaknesses, and while it's
not quite broken, it's easy to misuse. If a system creator uses a real
nonce, doesn't reuse the keystream, combines the key and the nonce
non-trivially, and discards the statistically-vulnerable beginning of
the keystream before using the rest, he's fine as far as the
cryptography goes.

A safer bet is to build a stream cipher out of a good block cipher (like
AES) by using CTR mode; another is to use a modern stream cipher. But
RC4 and cryptosystems using it aren't automatically broken in the same
way that, say, single-DES is.

(I'm sure you know all this; I'm saying it for the benefit of the people
following along at home, including the OP.)

A far bigger problem with SwaTWT is that there's no message
authentication, meaning that modified (and truncated!) messages can go
undetected. OP, authenticate the message somehow, and use a real
authenticator like HMAC-SHA1 (or SHA256 if you want to be politically
correct). If space is a problem, truncate the hash output: it's still a
lot better than something weak like CRC32, and infinitely better than
using no authentication at all.

You can't fit all this into 100 lines of Javascript. It's best not to try.

> http://github.com/thedod/SwaTwt/blob/master/index.html#L161

Is your point that Math.Random() may not be a particularly good PRNG?

> This is a bad design, bad algorithm, and bad implementation. Do not
> use it for anything you wish to keep secret.

You're right as far as the facts go.

I recall reading about a port of the OTR protocol to SMS; it uses ECC
instead of DSA to deal with the size constraints. Using Twitter as the
transport for this scheme should be straightforward. In addition to
being robust, this Twitter system should (in principle) be interoperable
with the OTR-over-SMS one. OP, implement this protocol in a signed
client-side application and you may create something worth using.

Regards,
Daniel Colascione



[1] If https://bugzilla.mozilla.org/show_bug.cgi?id=470897 doesn't scare
the pants off you, you're not paying attention.