Generic/ASN.1 | KeyFactory |

**Description:**- For public keys, this KeyFactory uses the format of a BER or DER-encoded
SubjectPublicKeyInfo object, as defined in X.509 and RFC 1422 (and also given
in PKCS #6 appendix A.1):
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL }

The BIT STRING for 'subjectPublicKey' is generally a BER or DER encoding of some algorithm-dependent type (e.g. RSAPublicKey for RSA), which is converted to a bit string in the obvious way (i.e. the most significant bit of the first octet becomes the first bit of the string, etc.)For private keys, the format is that of a BER or DER-encoded PrivateKeyInfo object, as defined in PKCS #8 (section 6):

PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute

The OCTET STRING for 'privateKey' is generally a BER or DER encoding of some algorithm-dependent type (e.g. RSAPrivateKey for RSA). 'version' is 0 for the current version of PKCS #8 (although for forward compatibility, other values MUST be accepted on input). The 'attributes' field is intended for information that would not be considered part of a private key according to the SCAN conventions, and therefore it SHOULD be ignored on input, and omitted on output.This format is not algorithm-specific, since the 'algorithm' field of AlgorithmIdentifier specifies the key family, and therefore keys from different families (e.g. RSA, DSA, etc.) can be unambiguously distinguished.

Generic/ASN.1 SHOULD normally be implemented by expressing the algorithm OID as a dot-separated string, then looking up an algorithm-specific KeyFactory based on that string, e.g. "1.2.3.4" if the OID is { 1 2 3 4 }. This allows new public key algorithms to be added without having to change existing classes.

Output MUST be encoded as DER.

**References:**- [
*Def*] S. T. Kent, J. Linn,

"Privacy enhancement for Internet electronic mail: Part II: Certificate-based key management,"

RFC 1422, February 1993. - [
*Def*] PKCS #6: Extended-Certificate Syntax Standard,

An RSA Laboratories Technical Note, Version 1.5. Revised November 1, 1993.

ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-6.asc - [
*Def*] PKCS #8: Private-Key Information Syntax Standard,

An RSA Laboratories Technical Note, Version 1.2. Revised November 1, 1993.

ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-8.asc - [
*Inf*] ITU-T Recommendation X.690 (1994), Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (equivalent to ISO/IEC 8825-1: 1995).

- [

Generic/Base64-ASN.1 | KeyFactory |

**Description:**- This factory uses the same underlying encoding as
Generic/ASN.1, but converted to
a restricted set of ASCII characters using Base64 (RFC 2045).
Generic/Base64-ASN.1 should normally be implemented in the same way as Generic/ASN.1, i.e. by expressing the algorithm OID as a dot-separated string, then looking up an algorithm-specific KeyFactory based on that string, e.g. "1.2.3.4" if the OID is { 1 2 3 4 }. This allows new public key algorithms to be added without having to change existing classes.

The encoding is an ASCII representation of the BER or DER data after being converted to Base64 format, with the header line

`"-----BEGIN PUBLIC KEY-----"`

, and the trailer line`"-----END PUBLIC KEY-----"`

. On output, each line MUST end with CR LF, and there MUST be no more than 72 ASCII characters per line, with no whitespace. On input, whitespace and non-standard line endings MUST be ignored. **References:**- [see references for Generic/ASN.1]
- [
*Inf*] "Multipurpose Internet Mail Extensions (MIME) Part One, Format of Internet Message Bodies,"

RFC 2045 Section 6.8 - Base64 Content-Transfer-Encoding.

http://www.imc.org/rfc2045

DH/OpenPGP | KeyFactory |

**Alias:**- "ElgamalEnc/OpenPGP"
**Description:**- A KeyFactory for OpenPGP-encoded DH public and private keys, as
defined in RFC 2440. Version 4 key packets MUST be supported.
A version 4 packet contains:

- A one-octet version number (4).
- A four-octet number denoting the time that the key was created (unsigned number of seconds elapsed since midnight, 1 January 1970 UTC).
- A one-octet number denoting the public key algorithm of this key (16 = Elgamal encrypt only, 20 = Elgamal encrypt or sign).
- A series of multi-precision integers comprising the key
material. This algorithm-specific portion is:
- MPI of Elgamal prime
*p*; - MPI of Elgamal group generator
*g*; - MPI of Elgamal public key value
*y*(=*g*where^{x}*x*is secret).

- MPI of Elgamal prime

Implementations MAY ignore fields that are not considered part of a public key according to SCAN conventions (for example, the creation time). The version number field SHOULD be checked for correctness, and the public key algorithm field MUST be 16 or 20.

**References:**- [
*Def*] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer

"OpenPGP Message Format,"

RFC 2440, November 1998.

- [
**Comments:**- Since OpenPGP DH keys do not contain a specification of the order of the
subgroup generated by
*g*, the key SHOULD NOT have an`order`

parameter. This will result in the exponent*k*used for encryption being chosen from the range [1,*p*-1] (or possibly [2,*p*-2]), which matches the behaviour of existing OpenPGP implementations. - Despite the existence of algorithm number 20, designated as "Elgamal (Encrypt or Sign)" in the OpenPGP spec, it is not guaranteed to be valid to use this KeyFactory algorithm to create a public or private key that will be used for Elgamal signatures (ElgamalSig). Instead, use an ElgamalSig/OpenPGP KeyFactory.

- Since OpenPGP DH keys do not contain a specification of the order of the
subgroup generated by
**Security comment:**- Use of the same key pair for Elgamal signatures and encryption is not recommended.

DSA/OpenPGP | KeyFactory |

**Description:**- A KeyFactory for OpenPGP-encoded DSA public and private keys, as
defined in RFC 2440. Version 4 key packets MUST be supported.
A version 4 packet contains:

- A one-octet version number (4).
- A four-octet number denoting the time that the key was created (unsigned number of seconds elapsed since midnight, 1 January 1970 UTC).
- A one-octet number denoting the public key algorithm of this key (17 = DSA).
- A series of multi-precision integers comprising the key
material. This algorithm-specific portion is:
- MPI of DSA prime
*p*; - MPI of DSA group order
*q*(*q*is a prime divisor of*p*-1); - MPI of DSA public key value
*y*(=*g*where^{x}*x*is secret).

- MPI of DSA prime

Implementations MAY ignore fields that are not considered part of a public key according to SCAN conventions (for example, the creation time). The version number field SHOULD be checked for correctness, and the public key algorithm field MUST be 17.

**References:**- [
*Def*] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer

"OpenPGP Message Format,"

RFC 2440, November 1998.

- [

ECDH/ASN.1 | KeyFormat |

**Description:**- A KeyFactory for BER or DER-encoded ECDH public and private keys. ECDH
keys are very similar to those for ECDSA, which is defined in X9.62.
The current X9.62 draft does not define specific types
for keys; however it states that a public key is represented using the
ECPoint type. There is no agreed type for private keys; this algorithm
name is reserved for whatever is eventually specified.
ECDH public keys may have either 'explicit', 'named' or 'implicit' parameters:

Parameters ::= CHOICE { ecParameters ECParameters, namedCurve CURVES.&id({CurveNames}), implicitlyCA NULL }

If the parameters field of the algorithm identifier is of type ECParameters (defined below), it specifies the explicit parameters. If it is an OBJECT IDENTIFIER, it specifies a 'named' curve from ANSI X9.62. If it is NULL, the parameters will be implicit; in this case the key can only be used if an appropriate AlgorithmParameterSpec object is passed to the algorithm object when it is used.The other ASN.1 types used in ECDH keys are:

ECParameters ::= SEQUENCE { version INTEGER { ecpVer1(1) } (ecpVer1), -- version is always 1 fieldID FieldID { {FieldTypes} }, -- the finite field over which the curve is defined curve Curve, -- coefficients a and b of the elliptic curve base ECPoint, -- the base point P on the elliptic curve order INTEGER, -- the order n of the base point cofactor INTEGER OPTIONAL, -- #E(Fq)/n (used in parameter validation) ... } FieldElement ::= OCTET STRING Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL } ECPoint ::= OCTET STRING FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType}) OPTIONAL } FieldTypes FIELD-ID ::= { { Prime-p IDENTIFIED BY prime-field } | { Characteristic-two IDENTIFIED BY characteristic-two-field }, ... } FIELD-ID ::= TYPE-IDENTIFIER

[Note: the above is effectively equivalent to eitherFieldID ::= SEQUENCE { fieldType OBJECT IDENTIFIER, parameters Prime-p OPTIONAL -- when fieldType = prime-field }

*or*FieldID ::= SEQUENCE { fieldType OBJECT IDENTIFIER, parameters Characteristic-two OPTIONAL -- when fieldType = characteristic-two-field }

according to the value of`fieldType`

.]ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 } id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) } prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 } Prime-p ::= INTEGER -- Field size p (p in bits) Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m (m in bits) basis CHARACTERISTIC-TWO.&id({BasisTypes}), parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) } BasisTypes CHARACTERISTIC-TWO ::= { { NULL IDENTIFIED BY gnBasis } | { Trinomial IDENTIFIED BY tpBasis } | { Pentanomial IDENTIFIED BY ppBasis }, ... } CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER

[The interpretation of the &id and &Type notation is similar to FieldID above. For example, for a Trinomial basis:Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m (m in bits) basis OBJECT IDENTIFIER, parameters Trinomial -- when basis = tpBasis }

and similarly for Gaussian Normal and Pentanomial bases.]id-characteristic-two-basis OBJECT IDENTIFIER ::= { characteristic-two-field basisType(1) } gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

A trinomial basis over GF(2^{m}) with reduction polynomial*x*+^{m}*x*+ 1, is represented as the integer^{k}*k*:Trinomial ::= INTEGER

A pentanomial basis over GF(2

^{m}) with reduction polynomial*x*+^{m}*x*^{k3}+*x*^{k2}+*x*^{k1}+ 1, is represented as the integers*k*_{1},*k*_{2}and*k*_{3}(in order, with smallest first):Pentanomial ::= SEQUENCE { k1 INTEGER, k2 INTEGER, k3 INTEGER }

Output MUST be encoded as DER.

**Aliases:**- "1.2.840.10045.2.1"
**References:**- [
*Def*] X9.62-199x (draft), Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). - [
*Inf*] L. Bassham, D. Johnson, W. Polk,

Internet X.509 Public Key Infrastructure: Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates,

October 1999 Internet draft.

http://www.globecom.net/ietf/draft/draft-ietf-pkix-ipki-ecdsa-02.html

- [
**Patent status:**- [see general elliptic curve patents]

ECDSA/ASN.1 | KeyFactory |

**Description:**- A KeyFactory for BER or DER-encoded ECDSA public and private keys. ECDSA
is defined in X9.62. The current X9.62 draft does not define specific types
for keys; however it states that a public key is represented using the
ECPoint type. There is no agreed type for private keys; this algorithm
name is reserved for whatever is eventually specified.
ECDSA public keys may have either 'implicit' or 'explicit' parameters. If the parameters field of the algorithm identifier is NULL, the parameters will be implicit; otherwise this field is of type ECParameters (defined below), and specifies the explicit parameters.

A key with implicit parameters can only be used if an appropriate AlgorithmParameterSpec object is passed into the Signature object's setParameter method.

The ASN.1 types used in ECDSA keys are the same as those given above for ECDH/ASN.1. Output MUST be encoded as DER.

**Aliases:**- "1.2.840.10045.2.1"
**References:**- [
*Def*] X9.62-199x (draft), Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). - [
*Inf*] L. Bassham, D. Johnson, W. Polk,

Internet X.509 Public Key Infrastructure: Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates,

October 1999 Internet draft.

http://www.globecom.net/ietf/draft/draft-ietf-pkix-ipki-ecdsa-02.html

- [
**Patent status:**- [see general elliptic curve patents]

ElgamalSig/OpenPGP | KeyFactory |

**Description:**- A KeyFactory for OpenPGP-encoded Elgamal public and private signature
keys, as defined in RFC 2440. Version 4 key packets MUST be supported.
A version 4 packet contains:

- A one-octet version number (4).
- A four-octet number denoting the time that the key was created (unsigned number of seconds elapsed since midnight, 1 January 1970 UTC).
- A one-octet number denoting the public key algorithm of this key (20 = Elgamal encrypt or sign).
- A series of multi-precision integers comprising the key
material. This algorithm-specific portion is:
- MPI of Elgamal prime
*p*; - MPI of Elgamal group generator
*g*; - MPI of Elgamal public key value
*y*(=*g*where^{x}*x*is secret).

- MPI of Elgamal prime

Implementations MAY ignore fields that are not considered part of a public key according to SCAN conventions (for example, the creation time). The version number field SHOULD be checked for correctness, and the public key algorithm field MUST be 20.

**References:**- [
*Def*] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer

"OpenPGP Message Format,"

RFC 2440, November 1998. - [
*Inf*] D. Bleichenbacher,

"Generating ElGamal signatures without knowing the secret key,"

Advances in Cryptology - EUROCRYPT '96 (corrected version), Volume 1070 of Lecture Notes in Computer Science, pp. 10-18. Springer Verlag, 1996.

ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps

- [
**Comments:**- Despite the existence of algorithm number 20, designated as "Elgamal (Encrypt or Sign)" in the OpenPGP spec, it is not guaranteed to be valid to use this KeyFactory algorithm to create a public or private key that will be used for Elgamal encryption (ElgamalEnc). Instead, use an DH/OpenPGP (alias ElgamalEnc/OpenPGP) KeyFactory.

**Security comments:**- The paper by Bleichenbacher referenced above shows that if
*g*has only small prime factors, and if*g*divides the order of the group it generates, then signatures can be forged. Implementations MAY reject encoded keys that would be vulnerable to this attack (in Java, by throwing an InvalidKeySpecException). - Use of the same key pair for Elgamal signatures and encryption is not recommended.

- The paper by Bleichenbacher referenced above shows that if

× ESIGN/ASN.1 | KeyFactory |

**Designers:**- Wei Dai (ASN.1 format),

Eiichiro Fujisaki, Tatsuaki Okamoto (ESIGN) **Description:**- A KeyFactory for DER-encoded ESIGN public and private keys, as
defined in the IEEE P1363a draft standard. The ASN.1 public and
private key types are defined as follows:
ESIGNPublicKey ::= SEQUENCE { modulus INTEGER, -- n = p*p*q publicExponent INTEGER -- e } ESIGNPrivateKey ::= SEQUENCE { modulus INTEGER, -- n = p*p*q publicExponent INTEGER, -- e prime1 INTEGER, -- p prime2 INTEGER -- q }

Note that*n*is redundant in the private key.The bit length of

*n*MUST be a multiple of 3. That is, there is an integer*k*such that 2^{3k - 1}< n < 2^{3k}. Also,*e*satisfies 8 <=*e*<*n*and is relatively prime to*n*.For a private key,

*n*=*p*^{2}*q*and 2^{k-1}<*p*,*q*< 2^{k}MUST also hold.Output MUST be encoded as DER.

**References:**- [
*Def*] IEEE,

"Draft Standard Specifications for Public Key Cryptography Amendment 1: Additional Techniques,"

http://grouper.ieee.org/groups/1363/index.html - [
*Inf, An, Test, Impl, Patent*] Nippon Telegraph and Telephone Corporation,

ESIGN Signatures Homepage,

http://info.isl.ntt.co.jp/esign and

http://www.nttmcl.com/sec/Esign/esign.html

- [

RSA/ASN.1 | KeyFactory |

**Description:**- A KeyFactory for BER or DER-encoded RSA public and private keys, as
defined in X.509 and PKCS #1:
RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER -- (inverse of q) mod p } Version ::= INTEGER

The 'version' field in private keys is 0 for the current version of PKCS #1 (although for forward compatibility, other values MUST be accepted on input).Output MUST be encoded as DER.

**Aliases:**- "1.2.840.113549.1.1.1", "2.5.8.1.1"
**References:**- [
*Def*] PKCS #1: RSA Encryption Standard,

An RSA Laboratories Technical Note, Version 1.5. Revised November 1, 1993.

ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-1.asc - [
*Inf*] Bruce Schneier,

"Section 19.3 RSA,"

Applied Cryptography, Second Edition, John Wiley & Sons, 1996.

- [

RSA/OpenPGP | KeyFactory |

**Description:**- A KeyFactory for OpenPGP-encoded RSA public or private keys,
as defined in RFC 2440. Version 4 key packets MUST be supported;
version 3 packets MAY be supported.
A version 3 packet contains:

- A one-octet version number (3).
- A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire.
- A one-octet number denoting the public key algorithm of this key (1 = RSA encrypt or sign, 2 = RSA encrypt only, 3 = RSA sign only).
- A series of multi-precision integers comprising the key
material:
- MPI of RSA public modulus
*n*; - MPI of RSA public encryption exponent
*e*.

- MPI of RSA public modulus
- For private keys only:
- One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier.
- [Optional] If string-to-key usage octet was 255, a one-octet symmetric encryption algorithm.
- [Optional] If string-to-key usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above.
- [Optional] If secret data is encrypted, an eight-octet Initialisation Vector (IV).
- Encrypted multi-precision integers comprising the secret key
data. These algorithm-specific fields are:
- MPI of RSA secret exponent
*d*. - MPI of RSA secret prime value
*p*. - MPI of RSA secret prime value
*q*(*p*<*q*). - MPI of
*u*, the multiplicative inverse of*p*, mod*q*.

- MPI of RSA secret exponent
- Two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536, stored in the clear).

Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initialisation Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non-prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data.

V3 keys SHOULD only be used for backward compatibility because of various weaknesses (see security comments).

A version 4 packet contains:

- A one-octet version number (4).
- A one-octet number denoting the public key algorithm of this key.
- A series of multi-precision integers comprising the key
material. This algorithm-specific portion is:
- MPI of RSA public modulus
*n*; - MPI of RSA public encryption exponent
*e*.

- MPI of RSA public modulus
- For private keys only:
- One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier.
- [Optional] If string-to-key usage octet was 255, a one-octet symmetric encryption algorithm.
- [Optional] If string-to-key usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above.
- [Optional] If secret data is encrypted, an eight-octet Initialisation Vector (IV).
- Encrypted multi-precision integers comprising the secret key
data. These algorithm-specific fields are:
- MPI of RSA secret exponent
*d*. - MPI of RSA secret prime value
*p*. - MPI of RSA secret prime value
*q*(*p*<*q*). - MPI of
*u*, the multiplicative inverse of*p*, mod*q*.

- MPI of RSA secret exponent
- Encrypted two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536).

Implementations MAY ignore fields that are not considered part of a public key according to SCAN conventions (for example, the creation time, and for V3 keys the validity period). The version number field SHOULD be checked for correctness, and the public key algorithm field MUST be 1, 2, or 3.

**References:**- [
*Def*] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer

"OpenPGP Message Format,"

RFC 2440, November 1998. - [
*Inf*] PKCS #1: RSA Encryption Standard,

An RSA Laboratories Technical Note, Version 1.5. Revised November 1, 1993.

ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-1.asc - [
*Inf*] Bruce Schneier,

"Section 19.3 RSA,"

Applied Cryptography, Second Edition, John Wiley & Sons, 1996.

- [
**Security comments:**- V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms.

Copyright and trademarks |