[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Remove SHOULD for elliptic curve groups in IKEv2



Title: RE: Remove SHOULD for elliptic curve groups in IKEv2
I must admit that I am somewhat skeptical as to the argument that anyone using 256 bit AES should be supporting public key mechanisms of equivalent strength.
 
First, the main application I would see for 256 bit AES would be to encrypt private key parameters in PKCS#12 type applications so one would expect to use a stronger symmetric cipher than public cipher.
 
I would expect that most implementations of AES would implement all three cipher strengths as the additional cost of doing so is minimal. The same cannot be said for adding in new public key algorithms.
 
If I did choose to enable 256 bit AES on a system it would not be for fear that someone might break 128 bit AES through brute force, it is more likely that I would be concerned about some new cryptanalytic technique (c.f. differential cryptanalysis) against AES and would want to take advantage of the additional security provided by the extra rounds.
 
The next generation of public key algorithms that I am interested in is public key algorithms that have a high work factor against quantum computing attacks.
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Mark Winstead [mailto:Mark.Winstead@NetOctave.com]
Sent: Tuesday, March 12, 2002 8:40 AM
To: ipsec@lists.tislabs.com
Subject: RE: Remove SHOULD for elliptic curve groups in IKEv2

Today it is fewer than 10%, but can't something close to that be said, at least recently, for AES?

With AES and its increased key sizes coming, shouldn't more EC groups be included? some with SHOULD for support of AES various key sizes and some additional MAYs? I believe consideration should be given to adding SECG's sect283k1 (a.k.a. 9th Oakley, ansit283k1), sect283r1 (8th, ansit283r1), sect409k1 (11th, ansit409k1), sect409r1 (10th, ansit409r1), sect571k1 (13th, ansit571k1), sect571r1 (12th, ansit571r1) to the draft, and perhaps secp256r1 (ansip256r1), secp384r1 (ansip384r1), and secp521r1 (ansip521r1). (See http://www.secg.org/collateral/sec2.pdf or ANSI 9.63)

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Monday, March 11, 2002 11:09 PM
> To: ipsec@lists.tislabs.com
> Subject: Remove SHOULD for elliptic curve groups in IKEv2
>
>
> Elliptic curve groups have barely been tested for interoperability.
> The SHOULDs in section 8.3 and 8.4 should be reduced to MAYs. As
> wonderful as EC cryptography is supposed to be, it is overkill to
> make it a near-requirement when probably fewer than 10% of
> implementations today use it.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

Phillip Hallam-Baker (E-mail).vcf