NTLMSSP signing stuff
eric.glass at comcast.net
eric.glass at comcast.net
Thu Aug 14 19:14:07 GMT 2003
I've been looking at NTLMSSP signing, specifically as used by the SSPI
MakeSignature function (I *think* these are the same keys used in
CIFS signing, but I'm not sure; someone could probably verify/refute). In case
some of this is new knowledge, I figured I'd put it up here; I'm also going to
be adding a section on signing and sealing to my NTLM documentation at:
but I'm going to try and tie up some loose research ends first. Anyways,
Not really a scheme as such. Used if the SSPI context is initialized
without specifying integrity support. If the "Negotiate Always Sign" NTLM
flag is negotiated, then a call to MakeSignature will result in the
If Negotiate Always Sign is not specified, you will get an error indicating
that signatures are not supported by the provider.
The basic signature scheme is (roughly):
version + RC4(signingKey, '????' + CRC32(message) + SeqNum)
Version number is 32-bit little endian ('01000000').
SeqNum is a 32-bit LE sequence number, incremented after every signing,
starting at zero with the first signature.
The RC4 ciphertext is appended to the version number, and bytes 4-7 are
overwritten by a pseudorandom counter; after a couple hundred signatures,
it degenerates into a repeating sequence. The signature verifies
successfully with *any* value there, so it appears to be purely for
obfuscation (possibly to confound cryptanalysis).
The '????' is 4 bytes passed into the cipher along with the CRC and
the sequence number; I don't know what they are, and it doesn't matter
since the resultant ciphertext is overwritten by the counter value anyways.
An example is:
Which breaks out as:
f8930c00 Counter value
f1ee2b3d25fa1af3 RC4(signingKey, '????' + CRC32(message) + SeqNum)
Under this scheme, I have identified the following signing key variants
(I believe some/most/all of these are previously known):
User Session Key
Signing key is MD4(ntlmHash); or, if no NTLM response was provided
(i.e., Win9x clients), first 8 bytes of lmHash padded with 8 null bytes.
This is used when the "Negotiate Lan Manager Key" NTLM flag is *not*
set, most notably in LMCompatibilityLevel = 2 (where the LM response
is not sent). Note that since this is based solely on the hashes
(rather than the responses) the only entropy comes from the passwords;
the resulting signatures are the same for all challenges.
User Session Key w/Key Exchange
Same as above, but the "Negotiate Key Exchange" NTLM flag is
negotiated. A "session key" is sent in the Type 3 message.
The signing key is RC4(userSessionKey, sessionKey); that is, the
session key sent in the Type 3 message is RC4-encrypted using the
user session key from above; the resulting value is used as the
Lan Manager Key (40-bit)
Used when the "Negotiate Lan Manager Key" NTLM flag is negotiated,
and "Negotiate 56" is *not* set.
The signing key is DES(lmHash[0-6], lmResponse[0-7])[0-4] + '0xe538b0';
that is, the first 8 bytes of the LM response are DES-encrypted using
the first 7 bytes of the LM hash as a key; the first 5 bytes of this
are taken and padded with the 3-byte constant '0xe538b0'. This value is
used as the signing key.
Lan Manager Key 56-bit
Same as 40-bit, but instead of 5 bytes padded with '0xe538b0', it is
7 bytes padded with the single byte '0xa0'. This is used when both
"Negotiate Lan Manager Key" and "Negotiate 56" are set.
Lan Manager Key w/Key Exchange
This is used when "Negotiate Lan Manager Key" and
"Negotiate Key Exchange" are set. The Type 3 session key is used
to mutate the signing key, but I haven't yet been able to determine
how (it's not simply RC4(lanManagerKey, sessionKey) as in the
user session key case).
There are additional variants employed when NTLMv2 authentication is used;
I'm still looking at those, as well as NTLM2 signing, but currently not really
More information about the samba-technical