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

[Benjamin Kaduk <[e-mail]>]

On Thu, 7 Nov 2013, Tom Yu wrote:

> Sam Hartman <[e-mail]> 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 agree (this is what I was trying to say in a previous message; I'm not 
sure how well it came through).

>> 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

I agree.

> 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 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.

> 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.

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

-Ben