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

[Greg Hudson <[e-mail]>]

On 10/04/2013 09:48 AM, Sam Hartman wrote:
> 1) Do you need any additional information to evaluate Paul's message?

I don't think so.  We are still curious about the details of legacy 
application risk (i.e. what kinds of things might a legacy SSPI 
application do wrong such that it works now but fails with a padded 
enctype), but the conclusion is pretty clear.

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

Yes; I think a CBC-padded enctype is more problematic for Microsoft than 
we had concluded based on previous input.  However, I am still 
uncomfortable with the amount of novel cipher mode design in 
http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01 to 
handle short inputs.

I am interested in the outcome of the discussion about using a 
confounder instead of an explicit IV.  Although confounders are less 
efficient than explicit IVs and less consistent with current 
cryptographic practice, using them does have several advantages 
(simplifying the CTS short-input problem down to the case of zero-length 
inputs; reducing the impact of PRNG compromise under specific threat 
mdels; allowing more implementation sharing with RFC 3962).

I have also spent some more time thinking about CTR mode as you 
suggested earlier (where we pick a random 128-bit nonce and use some 
function f(nonce, blocknum) to produce the counter for each block), and 
whether a nonce or block counter collision is any worse than a CBC 
cipher-block collision.  I noted that a CTR nonce collision would leak 
the XOR of the entire plaintexts of two multi-block messages, while a 
CBC cipher-block collision or only leaks the XOR of the plaintexts of 
the two colliding blocks, and a CBC IV/confounder collision only leaks 
information about how many blocks of two messages are identical.