Lan Manager security

[lws@transarc.com]

Have you seen an analysis of the security of the LanMan 
authentication scheme?  It strikes me as better than K4, but worse 
than K5.  I wonder if you concur.

Since Don and Ted have probably not seen this before, here's the 
technique as I understand it (summarized from the SAMBA docs).

The password is uppercased and truncated to 14 bytes (or padded to 14 
bytes with nulls).  This is split (0..6,7..13) into two DES keys 
which are each used to encrypt a static 8-byte value. The resulting 
16 byte key is stored at the server. 

To authenticate a connection, the server issues an 8 byte random 
challenge.
I presume this is returned in the clear since the docs don't specify 
otherwise, but I haven't sniffed one.  The randomness of the 
challenge doesn't matter so much if it crosses the network in the 
clear (though I can't understand why they did this), as long as the 
period of the generator is large enough to prevent replay attacks.

The client then pads the 16-byte key to 21 bytes (with zeros, natch), 
splits it in thirds, {0..6}, {7..13}, {14,15,NUL,NUL,NUL,NUL,NUL}, 
uses each third to DES-encrypt the challenge, concatenates the 
ciphertexts, and returns the response to the server.

I don't want to prejudice you too much by posting my own thoughts on 
this protocol, but here are a couple of things that should be obvious:
1. It doesn't hand back free samples of enciphered known plaintexts 
to all comers for offline attack.  This is a Good Thing, unlike some 
other NOTABLE EXAMPLES.
2. This business with padding the keys out with zero bits really 
simplifies cryptanalysis.  Where my limited expertise breaks down, is 
identifying just how easy it makes things.
3.  I'm kind of boggled as to why they do this multiple encryption of 
things and then *concatenate* the ciphertexts.  If you're going to do 
multiple encryption, it seems to make sense to pipeline the stages.  
Doesn't it?