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?