WASTE

[andrewducker]

WASTE is a new encrypted trusted chat/file transfer system I fancy trying out. If anyone else fancies giving it a go (Nathn, Dave, Guy, I'm looking at you) - gimme a shout.

Comments

[guyinahat.livejournal.com]

I've got it installed now, so if anyone else wants to join the experiment, let me know and I'll send you my public key

[protempore.livejournal.com]

yep, crepe2@jarday.com

and I need the duck's, too.

[ciphergoth.livejournal.com]

The crypto is emphatically not designed by someone who knows crypto...

[andrewducker]

Care to give me a pointer on the p[roblems with it?

[ciphergoth.livejournal.com]

The big warning sign is that their efforts at message integrity are completely screwy. Rather than using a known-good combination of a secure cipher and a secure MAC, they have this crazy homebrew concoction of PCBC mode and MD5. PCBC mode is not recommended for any purpose - it was originally intended to provide confidentiality and integrity in a single pass, but it certainly doesn't provide the latter and I don't think it's even been proven to provide the former. MD5 is also deprecated by none other than its inventors following Dobbertin's attacks on the compression function, and in any case the way it's used here is a half-arsed attempted to patch up the problems with message integrity.

A good sign here would be an encrypt-then-MAC combination of a known good encryption scheme, such as CBC or CTR mode, and a known good MAC, such as HMAC-SHA1, XCBC or OMAC. Rogaway and Wagner's EAX mode looks like a good choice, though they've yet to publish the proofs; Ferguson and Whiting's CCM is a feasable alternative though there are issues with it.

They use a different IV for each direction; best practice usually involves using a different key. And of course if they're reusing the same IV for different messages, as this seems to indicate, then they've really screwed up.

The choice of Blowfish instead of AES is also a bit weird in 2003 - to me it suggest either you've not been listening to the winds of change in the crypto world, or you're wearing a tinfoil helmet.

They say "Another unique feature is the way session keys are exchanged and combined so that in order to decrypt past (recorded) traffic, both private keys of a connection need to be recovered", which to me indicates that they don't know what perfect forward secrecy is.

These things give me a bad feeling, especially since there seems to be no reason to home brew a protocol rather than using SSL. I can see a dozen places in their protocol description where someone who knows about as much crypto as these people seem to could screw up. For example:

They don't say anything about what sort of padding they've used with RSA. I wouldn't be surprised if they were using raw RSA, which is insecure - if the thing about the "dictionary attack" means what I think it means then it's woefully insecure and they are fooling themselves badly about this "seems decent" thing.

TBH I'm starting to treat RSA as a warning sign in and of itself these days - it's widely used mostly because it's famous, and I can't think of any way it's better than, say, Rabin, which is always faster, and which unlike RSA and has a provable reduction to factoring.

There are many ways to misdesign a challenge-response protocol. Worst case, you provide a decryption oracle. If you provide real message integrity, then your initial "hello" messages will work in place of a challenge-response.

That's enough typing for now...