]> Aruba Networks

1322 Crossman avenue Sunnyvale California 94089 United States of America +1 408 227 4500 dharkins@arubanetworks.com

Security Internet Engineering Task Force elliptic curve, Diffie-Hellman This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

defines new elliptic curve domain parameters for curves over a number of different prime fields, each with a "twisted" variant. These curves have a number of interesting security properties (as described in ) that make them desirable to use. IANA maintains a registry for to map complete domain parameter sets into easily referenced numbers. While is deprecated, other protocols, for example and , refer to this registry for its convenience. Therefore, this memo instructs IANA to allocate new code points for the Brainpool curves defined in to the registry established by for use by other protocols.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

defines several elliptic curves over finite prime fields (ECP, in the parlance of ). The domain parameter sets for each of the elliptic curves defined in are copied here for convenient reference. The equation for all elliptic curves defined here is: y^2 = x^3 + ax + b (mod p) Domain parameter sets consist of: p: the prime a, b: parameters to the equation of the curve x, y: the coordinates of the generator for the group, G q: the order of the group formed by the generator G h: the co-factor z: the "twist" (for conversion into twisted curves) defines elliptic curves over seven (7) prime fields with a random and a "twisted" variety for each, for a total of fourteen (14) distinct curves. However, some of those curves are not particularly useful: the 160-bit curves provide only 80 bits of strength and that is too small to be of use in current cryptographic applications, and there is no standard hash function to use with the 196-bit and 320&nbhy;bit curves -- it would make more sense to use the 224-bit and 384-bit curves, respectively, instead. For this reason, the curves defined over 160-bit, 192-bit, and 320-bit primes are not being added to the registry created by . The twisted curves in are isomorphic to the random curves of the same length. The curve parameter "a" for the twisted curves equals -3 mod p, and there are certain arithmetical advantages to using such curves. It is possible to convert a point from a random curve (x,y) into a point on the twisted curve (x', y') and back again using this equation: (x',y') = (x*z^2, y*z^3) This would allow an implementation to internally use the twisted version of the curve, taking full advantage of the arithmetical advantages, while exchanging points on the random versions of the curve with peers. Therefore, the twisted curves are not being added to the registry created by . Implementations that desire to use the twisted curves internally MUST refer to for the complete domain parameter sets, only the "twist" is defined here.

Curve-ID: brainpoolP224r1

Curve-ID: brainpoolP256r1

Curve-ID: brainpoolP384r1

Curve-ID: brainpoolP512r1

IANA has assigned four values from the unassigned portion of the "Group Description" component of the registry and updated the registry by appending to the registry table. Value Group Description Reference Note 27 224-bit Brainpool ECP group RFC 6932 Not for RFC 2409 28 256-bit Brainpool ECP group RFC 6932 Not for RFC 2409 29 384-bit Brainpool ECP group RFC 6932 Not for RFC 2409 30 512-bit Brainpool ECP group RFC 6932 Not for RFC 2409

describes the security properties of the curves referenced here. The curves support security levels of 112 (), 128 (), 192 (), and 256 (). These security levels assume that when these elliptic curves are used with discrete logarithm cryptography, for example elliptic curve Diffie-Hellman, that the private key used is a uniformly random number in the range [1..(q-1)], where q is the order from the curve's domain parameter set. In order to achieve system security commensurate with the security level of a particular elliptic curve, it is incumbent upon an implementation to choose key derivation functions, hash functions, pseudo-random functions, and ciphers according to the recommendations from .

The notes in are an administrative prohibition, not a technical one. The notes are there because, although has been deprecated, it is still widely used. There is a desire among some in the IETF to not do anything that would prolong the use of , and the addition of these curves was perceived as doing just that. The registry could not have been updated without including notes to indicate that these curves are not for use with and not updating the registry would have a detrimental affect on the other protocols that use it.

&RFC2119; &RFC5639; IANA &RFC2409; &RFC5931; IEEE Computer Society National Institute of Standards and Technology The Brainpool Workgroup

This section provides some test vectors for example Diffie-Hellman key exchanges using each of the curves defined in . The following notation is used in subsequent sections: dA: the secret key of party A x_qA: the x-coordinate of the public key of party A y_qA: the y-coordinate of the public key of party A dB: the secret key of party B x_qB: the x-coordinate of the public key of party B y_qB: the y-coordinate of the public key of party B x_Z: the x-coordinate of the shared secret that results from completion of the Diffie-Hellman computation y_Z: the y-coordinate of the shared secret that results from completion of the Diffie-Hellman computation