[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AES, AES-MAC
On Mon, 21 May 2001, Jason Palmatier wrote:
>
> If AES-128 is being used as an encryption algorithm by IKE (or IPsec
> later), and IKE is generating the keys for it like it normally does, then
> doesn't IKE need a hash algorithm of size 256 bits or greater to create
> secure keys that are reasonably safe from collisions?
Not really. When generating the SKEYID_*, IKE really doesn't care about
collision attacks (finding two distinct preimages that happen to hash to
the same value). The attacker does not get the choose the values to be
hashed -- if he did, he'd be better off choosing values that gave a
known SKEYID, and using that. The attacker could wade through 2**64
distinct sessions, and hope to find a pair with the same (say) SKEYID_e
(leaving aside the questions of how he would recognize such a pair,
and how he could exploit it) but that same attack could be used against
just about any memoryless method of generating 128 bit AES keys, so that
is not an additional weakness.
> I was under the
> impression that for IKE to use AES-128 it would need a hash algorithm that
> produced an output of at least 256 bits to be secure. If I'm misguided
> here can someone let me know what the alternative is?
Because the SKEYID_e value is used to generate the encryption key, the
real restriction on prf length is that if you use a prf with a length
of n bits, then that IKE/IPSec session can be broken with no more than
O(2**n) effort. This implies that (for example) using AES-256 with
HMAC-MD5 is silly, because the extra key bits in AES-256 give you no
additional strength. However, using HMAC-MD5 with AES-128 does not add
such an additional weakness -- the attacker can cycle through all
possible 2**128 SKEYID_e values with O(2**128) effort, but then he can
cycle through all possible AES-128 keys with the same work factor, so that
doesn't buy the attacker anything.
>
> Jason
>
> Jason Palmatier
> IP Software Development
> IBM iSeries eServer
> Endicott, NY
> email: palmatie@us.ibm.com
>
>
>
>
>
> "Joseph D. Harwood"
> <jharwood@vesta-cor To: "Ipsec" <ipsec@lists.tislabs.com>
> p.com> cc: <jari.arkko@lmf.ericsson.se>
> Sent by: Subject: Re: AES, AES-MAC
> owner-ipsec@lists.t
> islabs.com
>
>
> 05/18/2001 01:19 PM
>
>
>
>
>
>
> >- I believe it is possible to use AES as
> > a MAC algorithm a la DES-MAC. Has this
> > been specified by NIST? Has it been specified
> > by IETF how to use it in the context of IPsec?
> >
> >- I seem to remember talk about SHA-256/384/512.
> > What are these and have their use been
> > specified for IPsec? What is their relationship
> > to AES-MAC?
>
> The thread on SHA-256/384/512 can be found here:
>
> http://www.vpnc.org/ietf-ipsec/mail-archive/msg00337.html
>
> These are hash algorithms from NIST with 256/384/512 bits of output. From
> the thread above I don't believe they are going to be a requirement for
> IPsec because of their performance. AES-MAC was also discussed in this
> thread. It's performance is roughly that of AES-CBC encryption/decryption.
> However, there has been discussion of using a counter mode for AES
> encryption/decryption rather than CBC mode to improve encryption/decryption
> performance, so perhaps something other than a straight AES-MAC would be
> needed for equivalent authentication performance. Please see the following
> message, which contains the slides from Steve Kent's presentation that
> discuss this:
>
> http://www.vpnc.org/ietf-ipsec/mail-archive/msg00168.html
>
> Best Regards,
> Joseph D. Harwood
> jharwood@vesta-corp.com
> www.vesta-corp.com
>
>
>
>
>
>
References: