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

From: Tom Yu <[email-masked]>
Date: Thu, 07 Nov 2013 14:47:11 -0500

Sam Hartman <[email-masked]> writes:

> Folks, I'd really appreciate input from those who responded to the AES
> CBC consensus call.
>
> 1) Do you need any additional information to evaluate Paul's message?

I would like more information on whethere there is likely to be any
way forward to make applications using the Windows encryption APIs
more capable of supporting padded CBC modes.  (This might include
improving the documentation of these APIs.)  I will need to review
some more MSDN documentation before I can ask the right questions
though.

I'm also fully willing to believe that encryption APIs providing
padded CBC modes are too difficult for application developers to
consistently write correct code for.

> 2) Has Paul's message caused you to revise your opinions in any way?

I think at this point we're best off standardizing something that
satisfies as many Suite B criteria as we can get consensus on, while
meeting the constraints of Windows applications that might not be
aware of a need to do padding.  To me, this means some variant of the
AES CTS mode that we described in RFC 3962.

I think the Suite B criteria that we might be able to satisfy include:

* Encrypt-then-MAC

* Full-length MAC using appropriate SHA-2 hashes

* Maybe explicit IV (though I prefer to continue using confounders for
  reasons I've already mentioned)

I think we can consider counter modes, but we should figure out how to
manage the nonce reuse/collision risks if we're going to do that.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Nov 2013 18:13:42 -0500 (EST)

> some more MSDN documentation before I can ask the right questions

I agree (this is what I was trying to say in a previous message; I'm not 
sure how well it came through).

> aware of a need to do padding.  To me, this means some variant of the

I agree.

>  reasons I've already mentioned)

I agree that we are likely to be able to satisfy these three.
I think Greg mentioned some key derivation functions at some point, which 
we can probably also do.  (I don't have the details handy just at the 
moment.)

I'm still undecided on the confounder vs. IV question and sort of think we 
should seek external input.

> manage the nonce reuse/collision risks if we're going to do that.

I'm not sure who is prepared to put time into researching counter modes.

-Ben