--- draft-jivsov-openpgp-ecc-10.txt 2012-03-07 12:38:40.914837576 -0800 +++ draft-jivsov-openpgp-ecc-11.txt 2012-03-20 14:51:03.563130407 -0700 @@ -4,28 +4,27 @@ Network Working Group A. Jivsov Internet Draft Symantec Corporation -Intended status: Standards March 7, 2012 -Expires: September 3, 2012 +Intended status: Standards March 20, 2012 +Expires: September 16, 2012 ECC in OpenPGP - draft-jivsov-openpgp-ecc-10.txt + draft-jivsov-openpgp-ecc-11.txt Abstract - This document proposes an Elliptic Curve Cryptography extension to + This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow - set of parameters for best interoperability and it does so within - the framework it defines that can be expanded in the future to - allow more choices. + set of parameters for easier interoperability between compliant + OpenPGP implementations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. @@ -45,16 +44,17 @@ http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 3, 2012. + This Internet-Draft will expire on September 16, 2012. Copyright Notice -A. Jivsov Expires September 3, 2012 [Page 1] + +A. Jivsov Expires September 16, 2012 [Page 1] Internet-Draft ECC in OpenPGP March 2012 Copyright (c) 2011 IETF Trust and the persons identified as the @@ -94,79 +94,79 @@ 15.1. Normative references..................................13 15.2. Informative references................................14 1. Introduction - The OpenPGP protocol supports RSA and DSA public key formats. This - document defines the extension to incorporate support for public - keys that are based on Elliptic Curve Cryptography (ECC). + The OpenPGP protocol [RFC4880], supports RSA and DSA public key + formats. This document defines the extension to incorporate + support for public keys that are based on Elliptic Curve + Cryptography (ECC). 2. Conventions used in this document 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 [RFC2119]. - -A. Jivsov Expires September 3, 2012 [Page 2] +A. Jivsov Expires September 16, 2012 [Page 2] Internet-Draft ECC in OpenPGP March 2012 - An application MAY implement this draft; note that any [RFC2119] - keyword within this draft applies to an OpenPGP application only if - it chooses to implement this draft. + Any implementation MAY follow the format and methods specified in + this document, in which case such an implementation is called a + compliant application. Note that any [RFC2119] keyword within this + document applies to an OpenPGP application only if it chooses to be + a compliant application. 3. Elliptic Curve Cryptography - This specification establishes the minimum set of Elliptic Curve + This document establishes the minimum set of Elliptic Curve Cryptography (ECC) public key parameters and cryptographic methods that will likely satisfy the widest range of platforms and applications and facilitate interoperability. It adds a more efficient method for applications to balance the overall level of security with any AES algorithm specified in [RFC4880] than by simply increasing the size of RSA keys. - This document defines a path to expand ECC support in the future. + National Security Agency (NSA) of the United States specifies ECC - for use in its [Suite B] set of algorithms. This specification - includes algorithms required by Suite B that are not present in - [RFC4880]. + for use in its [Suite B] set of algorithms. This document includes + algorithms required by Suite B that are not present in [RFC4880]. [KOBLITZ] provides a thorough introduction to ECC. 4. Supported ECC curves - This standard references three named prime field curves, which are - defined in [FIPS 186-3] as "Curve P-256", "Curve P-384", and "Curve - P-521". + This document references three named prime field curves, defined in + [FIPS 186-3] as "Curve P-256", "Curve P-384", and "Curve P-521". The named curves are referenced as a sequence of bytes in this - specification, called throughout this document as Curve OID. - Section 11 describes in details how this sequence of bytes is - formed. + document, called throughout this document as Curve OID. Section 11 + describes in details how this sequence of bytes is formed. 5. Supported public key algorithms Supported public key algorithms are Elliptic Curve Digital - Signature Algorithm (ECDSA), defined in [FIPS 186-3], and Elliptic - Curve Diffie-Hellman (ECDH), defined in section 8. A compatible - specification of ECDSA is given in [RFC6090] as "KT-I Signatures" - and in [SEC1]. + Signature Algorithm (ECDSA) [FIPS 186-3] and Elliptic Curve Diffie- + Hellman (ECDH), defined in section 8. A compatible specification + of ECDSA is given in [RFC6090] as "KT-I Signatures" and in [SEC1]. - The section 9.1. Public-Key Algorithms of [RFC4880] is expanded to - define the following public key algorithm IDs: + The following public key algorithm IDs are added to expand the + section 9.1. Public-Key Algorithms of [RFC4880]: -A. Jivsov Expires September 3, 2012 [Page 3] + + +A. Jivsov Expires September 16, 2012 [Page 3] Internet-Draft ECC in OpenPGP March 2012 ID Description of algorithm @@ -177,17 +177,17 @@ 19 ECDSA public key algorithm - Applications MUST support ECDSA and ECDH. + Compliant applications MUST support ECDSA and ECDH. 6. Conversion primitives - This specification only defines uncompressed point format. The - point is encoded in MPI format. The content of the MPI is the - following: + This document only defines uncompressed point format. The point is + encoded in the Multiprecision Integer (MPI) format [RFC4880]. The + content of the MPI is the following: B = B0 || x || y where x and y are coordinates of the point P = (x, y), each encoded in big endian format and zero-padded to the adjusted underlying @@ -207,29 +207,29 @@ "Curve P-256", 771 for "Curve P-256", and 1059 for "Curve P-521". This encoding is compatible with the definition given in [SEC1]. If other conversion methods are defined in the future, the - application MAY use them only when it is certain that every - recipient can support another format. + compliant application MAY use them only when it is certain that + every recipient can support another format. 7. Key Derivation Function A key derivation function (KDF) is necessary to implement EC encryption. The Concatenation Key Derivation Function (Approved -A. Jivsov Expires September 3, 2012 [Page 4] +A. Jivsov Expires September 16, 2012 [Page 4] Internet-Draft ECC in OpenPGP March 2012 - Alternative 1) defined in [NIST SP800-56A] is REQUIRED with the - following restriction: the KDF hash function MAY be based on any of - the following hash functions specified by [FIPS 180-3]: SHA2-256, + Alternative 1) [NIST SP800-56A] is REQUIRED with the following + restriction: the KDF hash function MAY be based on any of the + following hash functions specified by [FIPS 180-3]: SHA2-256, SHA2-384, SHA2-512. See section 13 for the details regarding the choice of the hash function. For convenience, the synopsis of the encoding method is given below with significant simplifications applicable to the choice of hash @@ -257,15 +257,15 @@ establish a shared secret, key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message. - One-Pass Diffie-Hellman method C(1, 1, ECC CDH), defined in [NIST - SP800-56A], MUST be implemented with the following restrictions: - ECC CDH primitive employed by this method is modified to always - assume the cofactor as 1, KDF specified in section 7 is used, and - KDF parameters specified below are used. + One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [NIST SP800-56A] + MUST be implemented with the following restrictions: ECC CDH + primitive employed by this method is modified to always assume the + cofactor as 1, KDF specified in section 7 is used, and KDF + parameters specified below are used. Key derivation function parameters MUST be encoded as concatenation of the following 5 variable-length and fixed-length fields: o a variable-length field containing curve OID, formatted as @@ -274,123 +274,123 @@ o a one-octet size of the following field -A. Jivsov Expires September 3, 2012 [Page 5] +A. Jivsov Expires September 16, 2012 [Page 5] Internet-Draft ECC in OpenPGP March 2012 - o octets representing curve OID, defined in section 11 + o octets representing curve OID, defined in section 11 - o a one-octet public key algorithm ID defined in section 5 + o a one-octet public key algorithm ID defined in section 5 - o a variable-length field containing KDF parameters, identical to - the corresponding filed in the ECDH public key, formatted as - follows + o a variable-length field containing KDF parameters, identical to + the corresponding filed in the ECDH public key, formatted as + follows - o a one-octet size of the following fields; values 0 and 0xff - are reserved for future extensions + o a one-octet size of the following fields; values 0 and 0xff + are reserved for future extensions - o a one-octet value 01, reserved for future extension + o a one-octet value 01, reserved for future extension - o a one-octet hash function ID used with KDF - o a one-octet algorithm ID for the symmetric algorithm used - to wrap the symmetric key for message encryption, see - section 8 for details + o a one-octet hash function ID used with KDF + o a one-octet algorithm ID for the symmetric algorithm used + to wrap the symmetric key for message encryption, see + section 8 for details - o 20 octets representing the UTF-8 encoding of the string - "Anonymous Sender " + o 20 octets representing the UTF-8 encoding of the string + "Anonymous Sender " - o 20 octets representing recipient encryption subkey or master key - fingerprint, identifying the key material that is needed for - decryption + o 20 octets representing recipient encryption subkey or master key + fingerprint, identifying the key material that is needed for + decryption - For three curves defined in this specification the size of the key - derivation parameters sequence, defined above, is either 54 or 51. + For three curves defined in this document the size of the key + derivation parameters sequence, defined above, is either 54 or 51. - The key wrapping method is based on [RFC3394]. KDF produces a - symmetric key that is used as KEK as specified in [RFC3394]. Refer - to section 13 for the details regarding the choice of the KEK - algorithm, which SHOULD be one of three AES algorithms. + The key wrapping method is based on [RFC3394]. KDF produces a + symmetric key that is used as KEK as specified in [RFC3394]. Refer + to section 13 for the details regarding the choice of the KEK + algorithm, which SHOULD be one of three AES algorithms. - The input to the key wrapping method is the value "m" derived from - the session key as described in section 5.1. Public-Key Encrypted - Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 - padding step is omitted. The result is padded using the method - described in [PKCS5] to the 8-byte granularity. For example, a - following AES-256 session key, which 32 octets are denoted from k0 - to k31, is composed to form the following 40 octet sequence: + The input to the key wrapping method is the value "m" derived from + the session key as described in section 5.1. Public-Key Encrypted + Session Key Packets (Tag 1) of [RFC4880], except, the PKCS#1.5 + padding step is omitted. The result is padded using the method + described in [PKCS5] to the 8-byte granularity. For example, a + following AES-256 session key, which 32 octets are denoted from k0 + to k31, is composed to form the following 40 octet sequence: - 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 + 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 - The octets c0 and c1 above denote the checksum. This encoding - allows the sender to obfuscate the size of the symmetric encryption - key used to encrypt the data. For example, assuming that an AES - algorithm is used for the session key, the sender MAY use 21, 13, - and 5 bytes of padding for AES-128, AES-192, and AES-256, + The octets c0 and c1 above denote the checksum. This encoding + allows the sender to obfuscate the size of the symmetric encryption + key used to encrypt the data. For example, assuming that an AES + algorithm is used for the session key, the sender MAY use 21, 13, + and 5 bytes of padding for AES-128, AES-192, and AES-256, -A. Jivsov Expires September 3, 2012 [Page 6] +A. Jivsov Expires September 16, 2012 [Page 6] Internet-Draft ECC in OpenPGP March 2012 - respectfully, to provide the same number of octets, 40 total, as an - input to the key wrapping method. + respectfully, to provide the same number of octets, 40 total, as an + input to the key wrapping method. - The output of the method consists of two fields. The first field - is the MPI with the ephemeral key used to establish shared - secret. The second field is composed of the following two fields: + The output of the method consists of two fields. The first field + is the MPI with the ephemeral key used to establish shared + secret. The second field is composed of the following two fields: - o a one octet, encoding the size in octets of the result of the - key wrapping method; the value 255 is reserved for future - extensions + o a one octet, encoding the size in octets of the result of the + key wrapping method; the value 255 is reserved for future + extensions - o up to 254 octets representing the result of the key wrapping - method, applied to the 8-byte padded session key, as described - above - Note that for session key sizes 128, 192, and 256 bits the size of - the result of the key wrapping method is, respectfully, 32, 40, and - 48 octets, unless size obfuscation is used. + o up to 254 octets representing the result of the key wrapping + method, applied to the 8-byte padded session key, as described + above + Note that for session key sizes 128, 192, and 256 bits the size of + the result of the key wrapping method is, respectfully, 32, 40, and + 48 octets, unless size obfuscation is used. - For convenience, the synopsis of the encoding method is given - below, however, this section, [NIST SP800-56A], and [RFC3394] are - the normative sources of the definition. + For convenience, the synopsis of the encoding method is given + below, however, this section, [NIST SP800-56A], and [RFC3394] are + the normative sources of the definition. - Obtain authenticated recipient public key R - Generate ephemeral key pair {v, V=vG} - Compute shared point S = vR; - m = symm_alg_ID || session key || checksum || pkcs5_padding; - curve_OID_len = (byte)len(curve_OID); - Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 - || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous - Sender " || recipient_fingerprint; - Z_len = key size for KEK_alg_ID to be used with AESKeyWrap - Compute Z = KDF( S, Z_len, Param ); - Compute C = AESKeyWrap( Z, m ) as per [RFC3394] - VB = convert point V to octet string - Output (MPI(VB) || len(C) || C). + Obtain authenticated recipient public key R + Generate ephemeral key pair {v, V=vG} + Compute shared point S = vR; + m = symm_alg_ID || session key || checksum || pkcs5_padding; + curve_OID_len = (byte)len(curve_OID); + Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 + || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous + Sender " || recipient_fingerprint; + Z_len = key size for KEK_alg_ID to be used with AESKeyWrap + Compute Z = KDF( S, Z_len, Param ); + Compute C = AESKeyWrap( Z, m ) as per [RFC3394] + VB = convert point V to octet string + Output (MPI(VB) || len(C) || C). - The decryption is the inverse of the method given. Note that the - recipient obtains the shared secret by calculating + The decryption is the inverse of the method given. Note that the + recipient obtains the shared secret by calculating - S = rV = rvG, where (r,R) is the recipient's key pair. + S = rV = rvG, where (r,R) is the recipient's key pair. - Consistent with section 5.13 Sym. Encrypted Integrity Protected - Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime - symmetric key is protected by ECDH. + Consistent with section 5.13 Sym. Encrypted Integrity Protected + Data Packet (Tag 18) of [RFC4880], the MDC SHOULD be used anytime + symmetric key is protected by ECDH. -A. Jivsov Expires September 3, 2012 [Page 7] +A. Jivsov Expires September 16, 2012 [Page 7] Internet-Draft ECC in OpenPGP March 2012 9. Encoding of public and private keys @@ -442,11 +442,11 @@ -A. Jivsov Expires September 3, 2012 [Page 8] +A. Jivsov Expires September 16, 2012 [Page 8] Internet-Draft ECC in OpenPGP March 2012 The following algorithm-specific packets are added to section @@ -475,11 +475,11 @@ 11. ECC curve OID The parameter curve OID is an array of octets that define the named curve. The table bellow specifies the exact sequence of bytes for - each named curve referenced in this specification: + each named curve referenced in this document: ASN.1 Object OID Curve OID bytes in Curve name in Identifier len hexadecimal [FIPS 186-3] representation @@ -498,11 +498,11 @@ one octet representing the Object Identifier tag and the second omitted field is the length of the Object Identifier body. For -A. Jivsov Expires September 3, 2012 [Page 9] +A. Jivsov Expires September 16, 2012 [Page 9] Internet-Draft ECC in OpenPGP March 2012 example, the complete ASN.1 DER encoding for the NIST P-256 curve @@ -511,18 +511,18 @@ 12. Compatibility profiles 12.1. OpenPGP ECC profile - Application MUST implement NIST curve P-256, MAY implement NIST - curve P-384, and SHOULD implement NIST curve P-521, defined in - section 11. Application MUST implement SHA2-256 and SHOULD - implement SHA2-512. Application MUST implement AES-128 and SHOULD - implement AES-256. + A compliant application MUST implement NIST curve P-256, MAY + implement NIST curve P-384, and SHOULD implement NIST curve P-521, + defined in section 11. A compliant application MUST implement + SHA2-256 and SHOULD implement SHA2-512. A compliant application + MUST implement AES-128 and SHOULD implement AES-256. - Application SHOULD follow section 13 regarding the choice of the - following algorithms for each curve: + A compliant application SHOULD follow section 13 regarding the + choice of the following algorithms for each curve: o the KDF hash algorithm o KEK algorithm @@ -534,11 +534,11 @@ It is recommended that the chosen symmetric algorithm for message encryption be no less secure than the KEK algorithm. 12.2. Suite-B profile - A subset of algorithms allowed by this specification can be used to + A subset of algorithms allowed by this document can be used to achieve [Suite B] compatibility. The references to [Suite B] in this document are informative. This document is primarily concerned with format specification, leaving additional security restrictions unspecified, such as matching assigned security level of information to authorized recipients or interoperability @@ -554,11 +554,11 @@ encryption must be AES-256. Hash algorithm restriction means that the hash algorithms of KDF and [RFC4880] message digest calculation must be SHA-384. -A. Jivsov Expires September 3, 2012 [Page 10] +A. Jivsov Expires September 16, 2012 [Page 10] Internet-Draft ECC in OpenPGP March 2012 12.2.2. Security strength at 128 bits @@ -571,11 +571,11 @@ Refer to [FIPS 186-3] B.4.1 for the method to generate a uniformly distributed ECC private key. The curves proposed in this document correspond to the symmetric key sizes 128 bits, 192 bits, and 256 bits as described in the - table below. This allows OpenPGP application to offer balanced + table below. This allows a compliant application to offer balanced public key security which is compatible with symmetric key strength for each AES algorithms allowed by [RFC4880]. The following table defines the hash and symmetric encryption algorithm that SHOULD be used with specific curve for ECDSA or ECDH. Stronger hash algorithm or symmetric key algorithm MAY be @@ -610,11 +610,11 @@ -A. Jivsov Expires September 3, 2012 [Page 11] +A. Jivsov Expires September 16, 2012 [Page 11] Internet-Draft ECC in OpenPGP March 2012 Curve name Recommended KDF Recommended KEK @@ -626,70 +626,74 @@ NIST curve P-521 SHA2-512 AES-256 - This specification explicitly discourages the use of algorithms - other than AES as a KEK algorithm because backward compatibility of - the ECDH format is not a concern. KEK algorithm is only used - within the scope of a Public-Key Encrypted Session Key Packet, - which represents an ECDH key recipient of a message. Compare this - with the algorithm used as the session key of the message, which - MAY be different from a KEK algorithm. - - Applications SHOULD implement, advertise through key preferences, - and use in compliance with [RFC4880] strongest algorithms specified - in this document. - - Note that [RFC4880] symmetric algorithm preference list may - restrict the use of balanced strength of symmetric key algorithms - for corresponding public key. For example, the presence of - symmetric key algorithms and their order in key preference list - affects the choices available to encoding side for compliance with - the table above. Therefore, applications need to be concerned with - this compliance throughout the life of the key, starting - immediately after key generation when the key preferences are first - added to a key. It is generally advisable to have a symmetric - algorithm of strength matching the public key at the head of the - key preference list. - - Often encryption to multiple recipients results in an unordered - intersection subset. For example, given two recipients, if the - first recipient's set is {A, B} and the second's is {B, A}, the - intersection is unordered set of two algorithms A and B. In this - case application SHOULD choose stronger encryption algorithm. - - Resource constraint, such as limited computational power, is the - likely reason why an application might prefer to use weakest - algorithms. On the other side of the spectrum are applications - that can implement every algorithm defined in this document. Most - applications are expected to fall into either of two - categories. An application in the second or strongest category - SHOULD prefer AES-256 to AES-192. + This document explicitly discourages the use of algorithms other + than AES as a KEK algorithm because backward compatibility of the + ECDH format is not a concern. KEK algorithm is only used within + the scope of a Public-Key Encrypted Session Key Packet, which + represents an ECDH key recipient of a message. Compare this with + the algorithm used as the session key of the message, which MAY be + different from a KEK algorithm. + Compliant applications SHOULD implement, advertise through key + preferences, and use in compliance with [RFC4880] strongest + algorithms specified in this document. + Note that [RFC4880] symmetric algorithm preference list may + restrict the use of balanced strength of symmetric key algorithms + for the corresponding public key. For example, the presence of + symmetric key algorithms and their order in the key preference list + affects the algorithm choices available to the encoding side, which + in turn may make unfeasible the adherence to the table + above. Therefore, compliance with this specification is a concern + throughout the life of the key, starting immediately after key + generation when the key preferences are first added to a key. It + is generally advisable to have a symmetric algorithm of strength + matching the public key at the head of the key preference list. -A. Jivsov Expires September 3, 2012 [Page 12] + Often encryption to multiple recipients results in an unordered + intersection subset. For example, given two recipients, if the + first recipient's set is {A, B} and the second's is {B, A}, the + intersection is unordered set of two algorithms A and B. In this + case a compliant application SHOULD choose stronger encryption + algorithm. + + Resource constraint, such as limited computational power, is the + likely reason why an application might prefer to use weakest + algorithms. On the other side of the spectrum are applications + that can implement every algorithm defined in this document. Most + applications are expected to fall into either of two categories. A + + + + +A. Jivsov Expires September 16, 2012 [Page 12] Internet-Draft ECC in OpenPGP March 2012 - While some statements in this specification refer to TripleDES + compliant application in the second or strongest category SHOULD + prefer AES-256 to AES-192. + + While some statements in this document refer to TripleDES algorithm, this is only done to help interoperability with existing - application and already generated keys; AES-256 is the recommended - alternative to TripleDES in all circumstances when AES-256 is - available. + OpenPGP applications and already generated keys; AES-256 is the + recommended alternative to TripleDES in all circumstances when AES- + 256 is available. SHA-1 MUST NOT be used for ECDSA or with KDF in ECDH method. MDC MUST be used when symmetric encryption key is protected by ECDH. None of the ECC methods described in this document are - allowed with deprecated V3 keys. The application MUST only use - Iterated and Salted S2K to protect private keys, as defined in + allowed with deprecated V3 keys. A compliant application MUST only + use Iterated and Salted S2K to protect private keys, as defined in section 3.7.1.3 Iterated and Salted S2K of [RFC4880]. 14. IANA Considerations + This document asks IANA to assign an algorithm number from OpenPGP Public-Key Algorithms range, or "name space" in the terminology of [RFC2434], that was created by [RFC4880]. Two ID numbers are requested, as defined in section 5. The first one with value 19 is already designated for ECDSA and currently unused, while another @@ -717,20 +721,19 @@ "Recommendation for Pair-WiseKey Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", March 2007 [FIPS 180-3] NIST, "Secure Hash Standard (SHS)", October 2008 - [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard - (AES) Key Wrap Algorithm", September 2002 - - -A. Jivsov Expires September 3, 2012 [Page 13] +A. Jivsov Expires September 16, 2012 [Page 13] Internet-Draft ECC in OpenPGP March 2012 + [RFC3394] J. Schaad, R. Housley, "Advanced Encryption Standard + (AES) Key Wrap Algorithm", September 2002 + [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based Cryptography Standard", March 25, 1999 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing IANA Considerations Section in RFCs", October 1998 @@ -738,13 +741,13 @@ 15.2. Informative references [KOBLITZ] N. Koblitz, "A course in number theory and cryptography", Chapter VI. Elliptic Curves, ISBN: 0-387-96576-9, Springer-Verlag, 1987 - [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", February 2011, + [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", September 20, 2000 Contributors @@ -775,10 +778,7 @@ - - - -A. Jivsov Expires September 3, 2012 [Page 14] +A. Jivsov Expires September 16, 2012 [Page 14]