[3359] in cryptography@c2.net mail archive
Fwd: Re: r.e. quality of IDEA...
daemon@ATHENA.MIT.EDU (Rodney Thayer)
Thu Sep 24 13:40:06 1998
Date: Thu, 24 Sep 1998 01:18:30 -0400
To: cryptography@c2.net
From: Rodney Thayer <rodney@tillerman.nu>
What do you mean, "key agility is an IPSec requirement"? If you mean you
must set up the keys fast, I disagree. You have to do this
humunguous D-H and an RSA operation to set up IKE, and if you're
careful overlapping Security Association set-up you can be
calculating one key schedule whilst still using the previous one.
>From: "John Kelsey" <kelsey@plnet.net>
>To: "Rodney Thayer" <rodney@tillerman.nu>, <cryptography@c2.net>,
> "David Honig" <honig@sprynet.com>
>Subject: Re: r.e. quality of IDEA...
>Date: Wed, 23 Sep 1998 23:23:17 -0500
>X-Mailer: Microsoft Internet Mail 4.70.1155
>
>> From: David Honig <honig@sprynet.com>
>> To: Rodney Thayer <rodney@tillerman.nu>; cryptography@c2.net
>> Subject: Re: r.e. quality of IDEA...
>> Date: Tuesday, September 22, 1998 10:49 PM
>
>> The NSA asked the NIST to request that AES ciphers
>> be able to encrypt 2 blocks with 2 keys in the same
>> time as 2 blocks with 1 key. Ie, ciphers you can search
>> rapidly are mucho desirable from the perspective
>> of the eye in the sky.
>
>With the key sizes involved in the AES candidates, speeding up the
>rekeying
>operation by a small constant factor makes no difference in security
>terms.
>2^{128} operations is not significantly faster than 521 * 2^{128}
>operations.
>However, there are some applications for which key agility is really
>important. IPSec is one example.
>
>Most of the AES candidates don't look like they pass this
>requirement.
>Twofish *almost* passes. We have to compute the S-box key from the
>initial
>key; everything else can then be done on the fly.
>
>CAST-256, DEAL, DFC, MARS, and RC6 certainly don't meet this
>requirement.
>
>I think Crypton, Rijndael, and SAFER+ meet the requirement, if you
>compute
>subkeys on the fly. It looks to me like E2 meets this requirement in
>the
>encryption direction, but not in the decryption direction. Serpent
>also
>meets this requirement in the encryption direction; I *think* you can
>do
>something clever to make it work as well in the decyption direction,
>as well.
>
>Note that in all cases, it's faster in software to precompute the
>subkeys once
>and reuse them many times. Twofish can also be made much faster for
>bulk encryption
>at the cost of an expensive per-key precomputation. I don't know of
>any other
>AES candidates that have that property. (Rijndael and Crypton can be
>sped up with
>large precomputed tables, but these tables aren't precomputed per
>key.)
>
>--John Kelsey, kelsey@counterpane.com / kelsey@plnet.net
>NEW PGP print = 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF
>
>Disclaimer: I am one of the designers of Twofish. Add grains of
>salt to taste.
>
>
>
>
>
>
>
>--John Kelsey, kelsey@counterpane.com / kelsey@plnet.net
>NEW PGP print = 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF
>
