1997-01-15 - Re: Hi again, and an invitation to kibitz

Header Data

From: amanda@intercon.com (Amanda Walker)
To: markm@voicenet.com>
Message Hash: 025587bb2ef65d5fa201ce1f05bd883b46775033b9bb11fb706be5589b945816
Message ID: <199701151541.KAA26095@mail.intercon.com>
Reply To: N/A
UTC Datetime: 1997-01-15 15:41:47 UTC
Raw Date: Wed, 15 Jan 1997 07:41:47 -0800 (PST)

Raw message

From: amanda@intercon.com (Amanda Walker)
Date: Wed, 15 Jan 1997 07:41:47 -0800 (PST)
To: markm@voicenet.com>
Subject: Re: Hi again, and an invitation to kibitz
Message-ID: <199701151541.KAA26095@mail.intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


> > (b) Client sends Microsoft NT authentication response to the server
> >     (take the password in Unicode form, do an MD4 hash, pad with 0s to 21
> >     bytes, split into 3 7-byte groups, use these as DES keys to encrypt
> >     the challenge three times, send the 24-byte result as the response).
> 
> I think this can be strengthened in a few ways.  The third DES key generated
> using this technique has an effective keylength of 16 bits.

Correct.   This is the reason I've been thinking of switching to SHA-1,
which gives a 20-byte hash (leaving only one byte of zeros, which can
be filled in with some function of the other 20 bytes to arrive at 21 bytes).
I haven't found any hole opened by exposing the last two bytes of the MD4
hash, but it's the piece I'm most worried about just on general principles
(never expose more than you have to :)).  I'm currently using the NT
algorithm simply because I had it around and needed to get a demo working
for the show.  We're not tied to using it, although it would be useful
if we end up doing an NT version of the server (since NT stores the MD4
hashes of passwords, not the plaintext).

> I believe the D-H patent expires sometime in September or October this year.

Yup.  April was wishful thinking on my part; we won't adopt D-H until the
patent expires.

> Any unbroken cipher with a keyspace larger than that of DES would be better.

Yup.  I started with vanilla DES because I was worried about speed, but
as it turns out the cipher step has a negligible impact on performance.
I'm considering DES-EDE (the easy option), Blowfish (also pretty easy),
or the DES variant Bruce Schneier describes in Applied Cryptography, 2nd ed.
(the one with independent subkeys).  So far, DES-EDE and Blowfish are the
front runners, since they're the ones that have been poked at the most.
DES-EDE has the advantage that more people know what DES is (the "buzzword
compliance" factor).  I'm not inclined to make the cipher a user-configurable
option unless customers demand it, just to keep the user interface as simple
as humanly possible.


Amanda Walker
InterCon Systems Corporation





Thread