Nullsoft's WASTE communication system

[bear]

On 30 May 2003, Eric Rescorla wrote:

>bear <bear at sonic.net> writes:

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

I haven't gone source diving, but from the doc, I've been assuming
it's the third case.

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

That's reasonable.

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

Hmm.  I had missed that too.  I suppose in that case they would
lose nothing by using PCBC since there'd be no remaining message
for a bit error to screw up, but it's still a strange choice, and
not one that demonstrably gains them much either.

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

Ow.  Now hat _IS_ scary.  Making a strange choice is one thing, and
I tend to assume unless proven otherwise that strange choices don't
mean incompetence.  But not _knowing_ what choice you made is
entirely different.  Where the doc and the source diverge, the
explanations that involve competence get a lot harder to believe.

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

Okay, I was out of date.  My bad.  And you're definitely right about
future work.

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

Just BTW, I don't often have good things to say about the intel guys,
but I think that the hands-off policy during the AES selection process
was _EXACTLY_ the right thing for them to do.  It gives users of AES
a kind of confidence about being its being tamper-free that DES never
had, clears their agencies of tampering suspicion which helps foster
trust, and places responsibility for public security infrastructure in
public forums where it, IMO, belongs.  I'd agree with you about using
AES going forward, or if CPU time's not a serious issue, 3DES.

				Bear


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