Skip Menu |
 

Subject: IV problem with AES (krb5-1.3.2 beta2)
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: krb5-bugs@mit.edu
Date: Wed, 11 Feb 2004 16:49:13 -0500

I noticed a problem in the recent 1.3.2 beta code dealing with AES
IVs. There seems to be some confusion over what routine is
responsible for updating the IVs.

For example:
Looking at dk_encrypt.c, the ivec->data is updated with
the contents of the final block. However, in enc_provider/aes.c
the ivec is updated with the contents of block "n-2".
So, the ivec data update in krb5int_aes_dk_encrypt (dk_encrypt.c)
overrides the ivec data update done in krb5int_aes_encrypt
(aes.c). Which one is correct and which should be removed?

The same problem exists in the AES decrypt routines:
krb5_dk_decrypt_maybe_trunc_hmac overwrites the ivec data
written by krb5int_aes_decrypt.

-Wyllys Ingersoll
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2)
From: Ken Raeburn <raeburn@MIT.EDU>
Date: Wed, 11 Feb 2004 20:32:49 -0500
RT-Send-Cc:
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.

Ken
Subject: Re: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2)
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: Ken Raeburn <raeburn@MIT.EDU>
Cc: rt-comment@krbdev.mit.edu, krb5-prs@MIT.EDU
Date: Thu, 12 Feb 2004 08:11:11 -0500
RT-Send-Cc:
On Wed, 2004-02-11 at 20:32, Ken Raeburn wrote:
Show quoted text
> 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

Show quoted text
>
> Ken
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Date: Thu, 12 Feb 2004 15:00:30 -0500
Subject: Re: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2)
From: Ken Raeburn <raeburn@MIT.EDU>
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
On Thursday, Feb 12, 2004, at 08:14 US/Eastern, Wyllys Ingersoll via RT
wrote:
Show quoted text
> 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. :-)

Show quoted text
> 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).

Show quoted text
> 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
From: raeburn@mit.edu
Subject: CVS Commit
* dk_decrypt.c (krb5_dk_decrypt_maybe_trunc_hmac): New argument IVEC_MODE. If
clear, same old behavior. If set, copy out next to last block for CTS.
(krb5_dk_decrypt, krb5int_aes_dk_decrypt): Pass extra argument.
* dk_encrypt.c (krb5int_aes_dk_encrypt): For IV, copy out next to last block for
CTS.


To generate a diff of this commit:



cvs diff -r1.22 -r1.23 krb5/src/lib/crypto/dk/ChangeLog
cvs diff -r1.8 -r1.9 krb5/src/lib/crypto/dk/dk_decrypt.c
cvs diff -r1.9 -r1.10 krb5/src/lib/crypto/dk/dk_encrypt.c
From: raeburn@mit.edu
Subject: CVS Commit
* t_encrypt.c (compare_results): New function.
(main): Use it to check decryption results against the original plaintext. When
testing with cipher state, encrypt and then decrypt (and verify) two messages.
* Makefile.in (t_encrypt$(EXEEXT)): Depend on CRYPTO_DEPLIB.


To generate a diff of this commit:



cvs diff -r5.148 -r5.149 krb5/src/lib/crypto/ChangeLog
cvs diff -r1.89 -r1.90 krb5/src/lib/crypto/Makefile.in
cvs diff -r5.7 -r5.8 krb5/src/lib/crypto/t_encrypt.c
From: tlyu@mit.edu
Subject: CVS Commit
pullup from trunk


To generate a diff of this commit:



cvs diff -r5.136.2.9 -r5.136.2.10 krb5/src/lib/crypto/ChangeLog
cvs diff -r1.86.2.3 -r1.86.2.4 krb5/src/lib/crypto/Makefile.in
cvs diff -r5.6 -r5.6.2.1 krb5/src/lib/crypto/t_encrypt.c
cvs diff -r1.18.2.1 -r1.18.2.2 krb5/src/lib/crypto/dk/ChangeLog
cvs diff -r1.6.4.1 -r1.6.4.2 krb5/src/lib/crypto/dk/dk_decrypt.c
krb5/src/lib/crypto/dk/dk_encrypt.c