Re: [kitten] Input on Paul's concerns about aes-cbc

[[e-mail] (Martin Rex)]

Paul Miller (NT) wrote:
>
>  ... it would not be possible to do a fallback just for impacted
> callers as the cipher of the subsession key is chosen during the
> context establishment which is before the first call to
> EncryptMessage (GSS_Wrap analogue).  By the time we knew that the
> caller was not providing for padding, it would be too late to
> select differently.

That fallback isn't possible has been intuitively obvious, at least to me.


> 
> With the existing calling pattern used for DES in Windows, callers that
> did not pass in the SECBUFFER_PADDING into the EncryptMessage call would
> just fail when the buffer was not aligned.

Hmmm.

While I did write my code that calls SSPI's EncryptMessage() in 1999
(during W2K beta), and don't exactly remeber which documentation
I used,  The "MDSN Library October 2001 Platform SDK" contains
a description titled "SSPI/Kerberos Interoperability with GSS-API
with this code sample:

  // Need 3 descriptors - 2 for the SSP and one to hold the application data 
  in_buf_desc.cBuffers = 3;
  in_buf_desc.pBuffers = wrap_bufs;
  in_buf_desc.ulVersion = SECBUFFER_VERSION;
  wrap_bufs[0].cbBuffer = sizes.cbSecurityTrailer;
  wrap_bufs[0].BufferType = SECBUFFER_TOKEN;
  wrap_bufs[0].pvBuffer = malloc(sizes.cbSecurityTrailer);
  // This buffer holds the application data
  wrap_bufs[1].BufferType = SECBUFFER_DATA;
  wrap_bufs[1].cbBuffer = in_buf.cbBuffer;
  wrap_bufs[1].pvBuffer = malloc(wrap_bufs[1].cbBuffer);
  memcpy(wrap_bufs[1].pvBuffer, in_buf.pvBuffer, in_buf.cbBuffer);
  wrap_bufs[2].BufferType = SECBUFFER_PADDING;
  wrap_bufs[2].cbBuffer = sizes.cbBlockSize;
  wrap_bufs[2].pvBuffer = malloc(wrap_bufs[2].cbBuffer);
  maj_stat = EncryptMessage(&context,
          SignOnly ? KERB_WRAP_NO_ENCRYPT : 0,
          &in_buf_desc, 0);

// Send message to server


>
> There are several reasons that I think this is a significant risk.
> First of all, the documentation that Microsoft has for the
> EncryptMessage function for Kerberos has very little bearing on how
> the function should actually be used.  In fact, most of the document
> is incorrectly copied and pasted from SSL's documentation.

Would the above code really fail to work?

-Martin