Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01

["Paul Miller (NT)" <[e-mail]>]

I omitted the critical context for my statement.  We cannot follow the behavior in RFC3962 for short cipher texts if we are to use an IV instead of a confounder.

RFC3962 says this in section 5:

   Ciphertext stealing, as defined in [RC5], assumes that more than one
   block of plain text is available.  If exactly one block is to be
   encrypted, that block is simply encrypted with AES (also known as ECB
   mode).  Input smaller than one block is padded at the end to one
   block; the values of the padding bits are unspecified.

This behavior of using padding for text shorter than one block and not padding block sized inputs creates the ambiguity.  We just never encountered any problems due to the use of the confounder which prevents inputs smaller than one block from occurring.

The CTS behavior in draft-ietf-kitten-aes-cts-hmac-sha2 describes cipher text stealing from the nonce handling short inputs.  I do not have any strong feelings on IV versus confounder so long as we keep using CTS in a mode that can steal from the IV to handle short inputs.

-----Original Message-----
From: Peck, Michael A [mailto:[e-mail]] 
Sent: Tuesday, October 1, 2013 5:34 AM
To: Paul Miller (NT); Sam Hartman; Benjamin Kaduk
Cc: [e-mail]; Michiko Short
Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01

Hi Paul,

Your example plaintexts below wouldn't result in ambiguous behavior with PKCS #7 padding.
As described in RFC5652 Section 6.3, your second plaintext example would have a full block of padding added.

Our reasoning for using an explicit IV:
Comply with the definition of CBC in NIST SP 800-38A (or the definition of CTS in NIST SP 800-38A Addendum), it's the current standard cryptographic practice, and save an unnecessary encryption/decryption operation per message.


Mike


On 9/24/13 6:00 PM, "Paul Miller (NT)" <[e-mail]> wrote:

>Through GSS_Wrap, the fact that we are encrypting at least the header 
>per RFC 4121 ensures that the message is not less than one block.  The 
>use of the cipher suite in the context establishment could be a problem, however.
>
>Without the confounder to avoid the short message problem, there could 
>be ambiguity between what is CTS encoded to exact length and what is 
>padded when the cipher text is exactly one block length.  That is to 
>say that the plain texts:
>
>01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd
>01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01
>
>Would end up encrypting the same and could not be distinguished as the 
>former would need to PKCS #7 pad and the latter would just CBC the 
>single block.
>
>I'm sorry I missed a lot of the context from prior discussions, but 
>what is the reason for using a traditional IV instead of the 
>confounder?  I don't see a difference in security and using the 
>confounder like cipher text allows CTS for short inputs.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Sam Hartman
>Sent: Tuesday, September 24, 2013 7:42 AM
>To: Benjamin Kaduk
>Cc: [e-mail]; Michiko Short; Sam Hartman
>Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01
>
>>>>>> "Benjamin" == Benjamin Kaduk <[e-mail]> writes:
>
>    Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote:
>    >> Hi.  With my chair hat on, does anyone wish to re-open the
>    >> discussion of the CBC decision based on this late input?
>
>    Benjamin> No comment on that particular question as of yet, but I
>    Benjamin> would ask for a clarification from Paul -- when he says
>    Benjamin> that "We use CTS today with AES so the complexity penalty
>    Benjamin> for using it is already paid.  Using known-good code
>    Benjamin> reduces the chance of introducing new security holes.",
>    Benjamin> does this account for the difference between the existing
>    Benjamin> enctypes (17,18) and the propsed enctypes with respect to
>    Benjamin> the use of a confounder versus explicit initialization
>    Benjamin> vector, and the the corresponding need to special-case
>    Benjamin> short inputs in the new proposal?  I could not tell what
>    Benjamin> Microsoft's position on the short-input behavior was from
>    Benjamin> Paul's initial message.
>
>well, I can't think of a way to get to a short-input case throguh SSPI.
>
>It seems like we're having the discussion, so that bar has been reached.
>_______________________________________________
>Kitten mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/kitten
>_______________________________________________
>Kitten mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/kitten