From: lws@transarc.com
To: beaver@transarc.com
Message Hash: 3dc772929e447f369d4dc8f9bebe84cb63819a21a0137ae0c247b00194676801
Message ID: <9601221620.AA11356@capybara.transarc.com>
Reply To: N/A
UTC Datetime: 1996-01-22 16:21:38 UTC
Raw Date: Mon, 22 Jan 96 08:21:38 PST
From: lws@transarc.com
Date: Mon, 22 Jan 96 08:21:38 PST
To: beaver@transarc.com
Subject: Lan Manager security
Message-ID: <9601221620.AA11356@capybara.transarc.com>
MIME-Version: 1.0
Content-Type: text/plain
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?
Return to January 1996
Return to “lws@transarc.com”
1996-01-22 (Mon, 22 Jan 96 08:21:38 PST) - Lan Manager security - lws@transarc.com