Nullsoft's WASTE communication system

bear bear at sonic.net
Fri May 30 19:33:33 EDT 2003



On 30 May 2003, Eric Rescorla wrote:

>Bill Stewart <bill.stewart at pobox.com> writes:
>
>(0) Their messages don't appear have any sequence numbers, making them
>    potentially open to a wide variety of integrity attacks. They have some sort
>    of guid but unless you intend to keep a record of all guids through
>    a session (horrible) this is only a partial fix for replay and
>    not a fix at all for removal.

Excellent point.  Sequence numbers aren't the only way to do
this, but they are probably the simplest.  Without them you
need to worry about replay and other integrity attacks.

>(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.
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.

However, MD5 may not be an example of a hash function that is still
trustworthy at this point. Dobberton (who is known to work for German
Intel) published a paper about collisions in MD5 that looks like it
might have been the 'toehold' that someone could climb to a full break
on, and then, conspicuously, did not publish any more papers about
MD5.  If he did manage to work it into a full break, he would not have
been allowed by his employers to publish.  And if he proved that a
full break based on that toehold was not possible, he would not have
been allowed by his employers to publish.  And if he is still working
on it, there'd have been nothing *to* publish.  All three ways, we see
the same story.  And since his paper came out, there are excellent
odds he's not the only one trying to climb on that toehold.  So using
MD5 these days is largely a matter of whether you feel lucky or not.

I'd suggest a different hash function, or HMAC with a constant key.

>(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?

>(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.

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 think that a "perfect cipher" of Blowfish's
block size would necessarily be less secure than a "perfect" cipher of
AES' block size, but I'm not aware of any work demonstrating either to
be an example of a "perfect cipher". (Nor any methodology such work
could employ, for that matter).

Note, I'm using "perfect cipher" to mean that there is no method for
recovering a plaintext block or key from ciphertext that involves less
work than attempting decryption with all possible keys - a property
which, of course, cannot in practice be proven but which is useful to
consider as a lower constraint on key sizes, block sizes, etc.

			Bear




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



More information about the cryptography mailing list