Hi again, and an invitation to kibitz

Hello folks,

A couple of years ago I signed off of cypherpunks in annoyance at what I
thought was a high "fluff" level, and said I'm sign back on when I had
crypto software to talk about.  Well, I do and so I have :).

Last week at MacWorld Expo, we announced a new product designed to provide a
secure AppleTalk tunnel over the Internet; we'll be doing a public beta in
a few weeks, and expect to be shipping relatively soon after that, assuming
that the public beta goes well.

The initial version is moderately secure (that is to say, I believe that
the most effective attacks to be DES key search and a dictionary attack on the
user's pass phrase).  I'm interested in comments on weaknesses aside from the
use of 56-bit DES; I'm profiling DES-EDE and if it's fast enough we'll be
switching to that.

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

(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 have not been able to find any obvious weak points, even if MD4 is weak,
since the digest is not put on the wire--recovering the digest would require
recovering a DES key given a single known plaintext/ciphertext pair.

I would be very interested in
any weak points anyone can identify (particularly with step b, since that
would have repercussions beyond this little piece of software).

I would also be interested in the effects on anyone's analysis given the
following modifications:

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


Comments?  Catcalls :) ?


Amanda Walker
Senior Software Engineer
InterCon Systems Corporation

In article <199701140755.CAA04514@mail.intercon.com>,
Amanda Walker <amanda@intercon.com> wrote:
> (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).
> 
> (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).

Some weaknesses:

- It doesn't resist dictionary attacks (no salt) when the attacker can make
    one active probe (forge a fixed challenge and get the client's response).
- It doesn't stop replay attacks (replay a fixed challenge, now the same DES
    key is used, so replay DES-encrypted session data).
- DES-encryption doesn't provide message authentication against active
    attacks; use a MAC too.
- You should use independent DES keys for each direction of the connection.
- Also the DES encryption key doesn't change for each connection.  It should.

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