Generic/ASN.1 | KeyFactory |
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 AttributeThe 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.
Generic/Base64-ASN.1 | KeyFactory |
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.
DH/OpenPGP | KeyFactory |
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.
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.
DSA/OpenPGP | KeyFactory |
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.
ECDH/ASN.1 | KeyFormat |
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.
ECDSA/ASN.1 | KeyFactory |
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.
ElgamalSig/OpenPGP | KeyFactory |
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.
× ESIGN/ASN.1 | KeyFactory |
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 < p, q < 2k MUST also hold.
Output MUST be encoded as DER.
RSA/ASN.1 | KeyFactory |
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 ::= INTEGERThe '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.
RSA/OpenPGP | KeyFactory |
A version 3 packet contains:
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:
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.
Copyright and trademarks |