Update to NTLM docs
kai.blin at gmail.com
Wed Sep 6 18:56:50 GMT 2006
On Wednesday 06 September 2006 20:22, Eric Glass wrote:
> The second sealing operation had me puzzled for a bit; but it looks
> like the output buffer from the first sealing operation is being
> inadvertently passed as the input buffer for the second (i.e. rather
> than encrypting 0x000102030405060708 as the second message, it is
> encrypting 0x2097118ac9f028260b - the ciphertext from the first
Yeah, sorry. I hacked up the program I'm using for my wine tests, and usually
I have another decryption (client side) on that buffer so by the time the
second EncryptMessage happens, that buffer is decrypted again.
Unfortunately, this is not what I am doing wrong in my wine conformance tests.
I'll read over your answer a bit more and try to find a way to do a more sane
check of this.
> The attached is marked up with more details, but briefly:
> key = 0xae33a32dca8c9821844f740d5b3f4d6c
The key is (this being NTLMv1) at an offset of 216 bytes if the server context
Kai Blin, <kai Dot blin At gmail Dot com>
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20060906/297bb6c8/attachment.bin
More information about the samba-technical