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
-----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-----
In article <199701140755.CAA04514@mail.intercon.com>,
Amanda Walker
(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.
participants (3)
-
amanda@intercon.com
-
daw@cs.berkeley.edu
-
Mark M.