KeyFactory algorithms

[TODO: Generic/OpenPGP, DH/ASN.1, DSA/ASN.1, ElgamalSig/ASN.1, NR/ASN.1, p-NEW/ASN.1, RW/ASN.1]


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:


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:


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:

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:
Comments:
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:

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:


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 either
   FieldID ::= 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(2m) with reduction polynomial xm + xk + 1, is represented as the integer k:
   Trinomial ::= INTEGER

A pentanomial basis over GF(2m) with reduction polynomial xm + xk3 + xk2 + xk1 + 1, is represented as the integers k1, k2 and k3 (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:
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:
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:

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:
Comments:
Security comments:


× 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 23k - 1 < n < 23k. Also, e satisfies 8 <= e < n and is relatively prime to n.

For a private key, n = p2q and 2k-1 < pq < 2k MUST also hold.

Output MUST be encoded as DER.

References:


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:


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:

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

A version 4 packet contains:

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:
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.

Valid HTML 4.0 Valid CSS Copyright and trademarks