Subject: Re: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2)
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
Reply-To: wyllys.ingersoll@sun.com
To: Ken Raeburn <raeburn@MIT.EDU>
Cc: rt-comment@krbdev.mit.edu, krb5-prs@MIT.EDU
In-Reply-To: <tx1vfmd2ibi.fsf@mit.edu>
References: <rt-2229-9807.17.0220331752621@krbdev.mit.edu> <tx1vfmd2ibi.fsf@mit.edu>
Content-Type: text/plain
Message-Id: <1076591470.7268.29.camel@pebblebeach.wki.test.net>
MIME-Version: 1.0
Date: Thu, 12 Feb 2004 08:11:11 -0500
Content-Transfer-Encoding: 7bit
RT-Send-Cc: 
Content-Length: 963

On Wed, 2004-02-11 at 20:32, Ken Raeburn wrote:
> Ugh.  Good catch, thanks.  I thought we were doing better about doing
> it at the lower level. *sigh*
> 
> The DK code is going to have to stop updating the IV, but that means
> the 3DES code is probably going to have to start updating it, if it's
> not doing so already.

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.

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.  Why was CTS chosen again??? :)

-Wyllys

> 
> Ken
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs