Nullsoft's WASTE communication system

Eric Rescorla ekr at rtfm.com
Fri May 30 20:05:13 EDT 2003


bear <bear at sonic.net> writes:
> On 30 May 2003, Eric Rescorla wrote:
> >Bill Stewart <bill.stewart at pobox.com> writes:
> >(1) They use MD5 instead of HMAC for message authentication. Scary.
> 
> If MD5 itself is to be trusted as a hash function, this is not
> particularly scary.  They are using MD5 over encrypted data which
> includes a participant identifier; that means that in order to defeat
> message authentication, Mallory would need to be able to forge and
> encrypt a message with the known participant identifier, such that the
> encrypted message hashes to the same MD5 code.  I think this is not a
> bad fundamental design, if MD5 is to be trusted as a hash function.
There are three possibilities here:
E(M) || H(E(M)) -> This is radically insecure.
E(M) || H(M)    -> This is still quite dangerous.  If the attacker 
                   can somehow reset the IV, then they can mount
                   an attack on the first cipher block.
E(M || H(M))    -> This is hard to attack with block ciphers, but
                   easy with stream ciphers.

It looks to me like it's the third case, but I'm not totally sure.
In any case, a keyed hash would be much safer.

> Using a keyed hash like HMAC here in a way that relies on its keyed
> property would introduce key management issues, with the attendant
> risks of getting them wrong, which as far as I can tell are
> unnecessary in this application.
I don't understand what you mean here. They're already doing
key exchange for Blowfish. There's no reason you couldn't hash
the keys to generate MAC keys, as SSL does.

> >(2) They use the same encryption keys in both directions. At least
> >   they have the sense to run separate PCBC counters. However,
> >   based on the code it doesn't look like they reset the PCBC
> >   counters after a bad message is received so you may be able to
> >   mount a reflection attack.
> 
> Another excellent point.  Is there a good way to reset PCBC counters
> without requiring a key agreement protocol for the new counter value?
Actually, it looks like this is impossible since they claim that
they destroy the connection after a bad message. My bad.
Still, I'd prefer to see different keys for each direction.

> >(3) They use Blowfish (why not AES?) in PCBC mode (huh?)
> 
> PCBC mode, I'm guessing, was an attempt to simplify the security
> equations of the system by making it hard for Eve to pick up the
> thread of a communication in the middle.  The authors are relying on
> TCP/IP's error correction to prevent bit-errors in transmission, which
> makes this system unsuitable for any non-Internet applications.
I'm not sure how PCBC would be any better than CBC for this
application. FWIW, the source code appears to actually use CBC,
the doc notwithstanding. This isn't exactly confidence inspiring.

> Blowfish has been around longer than Rijndael; I think AES may not yet
> have gotten as much cryptographic attention as Blowfish's several-year
> headstart has given it.
I just looked in citeseer and it seems to me that AES has gotten much
more attention. It certainly will be getting much more in the future.
I consider AES best current practice and so do most of the
professional protocol designers I know. If one has some reason not to
use AES, then 3DES is the appropriate choice. I can't see any reason
to choose Blowfish.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list