Re: Two AES encryption modes?

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Dan" == Dan McDonald <danmcd@east.sun.com> writes:
    >> >2. You want to use manual keying and therefore may send more than one
    >> > packet with the same IV.  With CBC that doesn't compromise the >
    >> confidentiality of the data; with counter mode it does.
    >> 
    >> Nitpick: CBC is not really as secure as one might like if IV's repeat,
    >> however it is true that IV reuse hurts CTR mode much worse than CBC
    >> mode.
    >> 
    >> If you reuse the same IV with CBC mode, there is some minor compromise
    >> of message confidentiality (shared plaintext prefixes show through as
    >> shared prefixes in the ciphertexts); in comparison, IV reuse in CTR
    >> mode is more devastating (it reveals both plaintexts).

    Dan> Manual keying does NOT, I repeat NOT mean identical IVs.  The two
    Dan> implementations I worked on (NRL, Solaris) use random (for "random"
    Dan> == /dev/urandom strength) IVs regardless of how IPsec SAs are
    Dan> derived.

  I agree with you - implementations should never have to reuse IVs. 

  The question is whether CTR mode is sufficiently robust that we need never
standardize an AES CBC mode. The IV problem for CTR mode is lethal.
  The same behaviour applied to CBC mode is not much of a big deal.

  To me, this is a debate about how deep the security is - of course, 
use random IVs. Should something bad happen, and someone figure out either a
way to influence the IVs, or the prng or hash that was used to generate turns
out to be bad, then is there still anything to keep the barbarians out?
  ("You must be *#%&U*#$@{} random to storm this system")

  Those who derived the IV from ciphertext would get screwed if they didn't
start with a random IV. FreeSWAN does start with a random initial IV. It now
(as of last week, when we enabled the fix) uses a /dev/urandom seeded prng
for IV generation. 

  The people who I see that think that manually keying might be neat
are the PDA/phone people who just need to authenticate back to a single
gateway box. They might be in an environment where they haven't provided for
any sources of randomness such that they'd even have a useful /dev/random.

  I think that they can, and should fix this - certainly a wireless device
can just dd if=/dev/ether of=/dev/random - i.e. listen some static, but that
may require some thinking in the driver...

]    Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]  Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [
]    At the far end of some dark fiber - wait that's dirt!     |for everyone  [



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPUV6QIqHRg3pndX9AQE+AwP9HTPiPJyGNw3/HX9Soa2Evw0GXuM0RM3y
b9A9fP6cFIZG1T3IRTwcsoGmkage3kve/n3iY1cNgd7PtERCnLxBt+zTX3NNJS5a
Tx6KWeLe1SU/Gp1gC+27ljHoMt+hRfKA3qUK1fUJmgKcK1GmVns4vqN72alPWydt
gjP9xrmbqzg=
=4nee
-----END PGP SIGNATURE-----