Date: Thu, 12 Feb 2004 15:00:30 -0500
Subject: Re: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
MIME-Version: 1.0 (Apple Message framework v553)
From: Ken Raeburn <raeburn@MIT.EDU>
To: rt-comment@krbdev.mit.edu
Content-Transfer-Encoding: 7bit
In-Reply-To: <rt-2229-9826.19.884693594458@krbdev.mit.edu>
Message-Id: <1BE87308-5D96-11D8-ADEC-000A95909EE2@mit.edu>
RT-Send-Cc: 
Content-Length: 1139

On Thursday, Feb 12, 2004, at 08:14 US/Eastern, Wyllys Ingersoll via RT 
wrote:
> 3DES does not appear to have the same problem.  One (admittedly ugly)
> fix would be to have dk_encrypt/decrypt check the enctype before
> updating the IV and only do it for 3DES.

Right on both counts ... it is a simple fix, and it's ugly. :-)

> For AES, is it correct to use the final block as the next IV
> (currently being done in dk_encrypt/decrypt) or the n-2 block
> (which is what happens in aes.c) ?   Because CTS is an odd mode
> that swaps the final 2 blocks, it makes choosing the IV a little
> trickier.

Having the last block be incomplete makes things even trickier if you 
use it.  The updated drafts getting submitted clarify that for AES-CTS 
it's the next to last block (the one that would be the final block in 
"normal" CBC if it were not for the swap).

>   Why was CTS chosen again??? :)

Dropping the padding, especially for AES with its larger block size.  
And to widen the spec and exercise the code so that we can deal with 
something that isn't plain old CBC with padding, which clearly is 
giving us a little trouble...

Ken