Support SECBUFFER_STREAM, SECBUFFER_DATA on DecryptMessage

[jborean93]

The SSPI documentation for interop with GSSAPI uses the following example for decryption when dealing with gss_wrap

wrap_buf_desc.cBuffers = 2;
wrap_buf_desc.pBuffers = wrap_bufs;
wrap_buf_desc.ulVersion = SECBUFFER_VERSION; 

// This buffer is for SSPI.
wrap_bufs[0].BufferType = SECBUFFER_STREAM;
wrap_bufs[0].pvBuffer = xmit_buf.pvBuffer;
wrap_bufs[0].cbBuffer = xmit_buf.cbBuffer;

// This buffer holds the application data.
wrap_bufs[1].BufferType = SECBUFFER_DATA;
wrap_bufs[1].cbBuffer = 0;
wrap_bufs[1].pvBuffer = NULL;
maj_stat = DecryptMessage(
&context,
&wrap_buf_desc,
0, // no sequence number
&qop
);

// This is where the data is.
msg_buf = wrap_bufs[1];

There are 2 buffers used in this example

• SECBUFFER_STREAM - the encrypted bytes to decrypt
• SECBUFFER_DATA - empty buffer

During the decryption process SSPI will decrypt the stream contents in place and set the pvBuffer and cbBuffer to the location and length of the decrypted payload on return.

Right now DecryptMessage expects the SECBUFFER_TOKEN and SECBUFFER_DATA buffers to be used where the token is the encrypted message to decrypt and SECBUFFER_DATA is the "header" associated with that data. This is fine if you know the sizes of the header but in my case I do not and SECBUFFER_STREAM is needed.

[CBenoit]

Addressed by #100

[jborean93]

Looks like PR #100 only implemented it for Kerberos and PKU2U. Would we be able to re-open this issue until support for this with NTLM is also in place?

[CBenoit]

Oh! Sure. cc @awakecoding @RRRadicalEdward