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

Header Data

From: “Mark M.” <markm@voicenet.com>
To: Amanda Walker <cypherpunks@toad.com
Message Hash: 28434f97cc3f959784c244eb4f2116f17347f6cd44024be6ab7459e0be973dec
Message ID: <Pine.LNX.3.95.970114165358.495D-100000@eclipse.voicenet.com>
Reply To: <199701140755.CAA04514@mail.intercon.com>
UTC Datetime: 1997-01-14 22:15:59 UTC
Raw Date: Tue, 14 Jan 1997 14:15:59 -0800 (PST)

Raw message

From: "Mark M." <markm@voicenet.com>
Date: Tue, 14 Jan 1997 14:15:59 -0800 (PST)
To: Amanda Walker <cypherpunks@toad.com
Subject: Re: Hi again, and an invitation to kibitz
In-Reply-To: <199701140755.CAA04514@mail.intercon.com>
Message-ID: <Pine.LNX.3.95.970114165358.495D-100000@eclipse.voicenet.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 14 Jan 1997, Amanda Walker wrote:

> Here's a sketch of the protocol:
> 
> (a) Server sends 8-byte challenge to client
> 
> (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.  If the password
is concatenated with the MD4 hash of the password and hashed a second time,
the first five bytes of the second hash value can be concatenated with the
first hash value to form the 21 byte string.  If the method you describe is
used, the third key can be brute-forced trivially, and the last two bytes of
the MD4 hash of the password will be known to the attacker.  I don't know how
detrimental this is to the system, but I think it would be better if this was
fixed.

If something like a time-stamp, or even the 8 byte challenge string, is run
through MD4 along with the password, the session key would be different each
time.  This would protect against known-plaintext attacks.

> 
> (c) If authentication fails, close the connection.
> 
> (d) If authentication succeeds, all subsequent traffic is enccrypted with
>     DES in CFB mode.  Until April :), the DES key used is taken from the
>     first 7 bytes of the MD4 hash of the password (after April, we expect
>     to switch to Diffie-Hellman key exchange first, followed by a revised
>     authentication handshake).

I believe the D-H patent expires sometime in September or October this year.
Since GATT was passed, patents now have a lifetime of 20 years past filing
date.

> - Using SHA (160 bit hash) instead of MD4
> - Using DES-EDE (112 bit key) instead of DES
> - Using Blowfish in CFB mode instead of DES
> - Using RC5 in CFB mode instead of DES (not likely unless RC5 is cheap)
> - Using RC4 (40 bit key) instead of DES (not likely)

Any unbroken cipher with a keyspace larger than that of DES would be better.
Blowfish seems to be pretty strong, and it has the added bonus of having a
computation intensive key setup.  I don't see any problems with using MD4, but
since speed doesn't seem to be an issue, SHA1 would be a reasonable choice.
It is not known whether H(H(pass),pass) is secure, so a hash with a 20 byte
output would eliminate the potential problem I described above.


Mark
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQEVAwUBMtwGfyzIPc7jvyFpAQEBzgf/clSp9vQVSpC55TgEJ0NudtbQMQHNx9fD
wlpVMg5X27/Dyb++PmYVdidPj71zmGTdhwSn2o9+TpqBhgZ6pwn7OpQ3dqRP7Atd
N8yxhEma5zNK9Jz7ieM9tayaxFQuj8r5y9NhjdnoQMjX3by86QMAX8r6mEZzKr3m
D1nUF/TPyann5HxDcbFAaOrXbvxbpr4Ukx+BUpSX2kCRFPB6YEw+Uw2304KilNVg
2L/YZRWBvwyxOWfm2JP62YxswzFMNmmufHcM9blBTu3UexWnIScmdU4+LfQtNSU8
0ph2R2fjyq22PjIqmhlxODtn6AiVZt9C2xd6GW5uTmHvCaOhC8OCxg==
=ZTNy
-----END PGP SIGNATURE-----






Thread