- Description:
- [[need more detail]]
- References:
- [Inf] Whitfield Diffie et al,
"New Directions in Cryptography,"
IEEE Transactions on Information Theory, vol. IT-22, No. 6,
pp. 644-654. November 1976.
- PublicKey parameters:
-
BigInteger p [read] - the prime modulus, p
-
BigInteger g [read] - the base, g
-
BigInteger y [read] - the public value, gx mod p
- PrivateKey parameters:
-
BigInteger p [read] - the prime, p
-
BigInteger g [read] - the base, g
-
BigInteger x [read] - the private value, x
-
BigInteger y [read] - the public value, gx mod p
- Description:
- The key pair generation algorithm described in NIST FIPS PUB 186 for DSA.
- Alias:
- "1.2.840.10040.4.3"
- Length:
- The length, in bits, of the modulus p. This can
be any integer that is a multiple of 8, greater than or equal
to 512.
- References:
- [Def] U.S. National Institute of Standards and Technology,
"Digital Signature Standard,"
NIST FIPS PUB 186,
U.S. Department of Commerce.
http://www.itl.nist.gov/div897/pubs/fip186.htm and
http://www.itl.nist.gov/div897/pubs/186chg-1.htm
- [Inf] Bruce Schneier,
"Section 20.1 Digital Signature Algorithm (DSA),"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
- [Inf] IEEE P1363 (draft),
Standard for Public-Key Cryptography, 1998.
- [An] Serge Vaudenay,
"Hidden collisions on DSS,"
Advances in Cryptology - Crypto '96,
Volume 1109 of Lecture Notes in Computer Science, pp. 83-88.
Springer-Verlag, 1996.
ftp://ftp.ens.fr/pub/reports/liens/liens-96-9.A4.ps.Z
- PublicKey parameters:
-
BigInteger p [read] - the prime modulus, p
-
BigInteger q [read] - a prime factor of p-1, q
-
BigInteger g [read] - h(p-1)/q mod p,
where h is less than p-1 and g > 1
-
BigInteger y [read] - gx mod p
- PrivateKey parameters:
-
BigInteger p [read] - the prime, p
-
BigInteger q [read] - a prime factor of p-1, q
-
BigInteger g [read] - h(p-1)/q mod p,
where h is less than p-1 and g > 1
-
BigInteger x [read] - the private value, < q
-
BigInteger y [read] - gx mod p
- Parameter defaults:
- The following default parameter values are used for lengths of 512, 768,
and 1024 bits.
| Modulus
| Seed
| Counter
|
| 512 bits
| b869c82b 35d70e1b 1ff91b28 e37a62ec dc34409b
| 123
|
| 768 bits
| 77d0f8c4 dad15eb8 c4f2f8d6 726cefd9 6d5bb399
| 263
|
| 1024 bits
| 8d515589 4229d5e6 89ee01e6 018a237e 2cae64cd
| 92
|
- Aliases:
- "1.2.840.113549.1.1.1", "2.5.8.1.1"
- References:
- [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.
- PublicKey parameters:
-
BigInteger modulus [read] - the modulus, n
-
BigInteger publicExponent [read] - the public exponent, e
- PrivateKey parameters:
- Either, or both, of the following two sets of parameters:
-
BigInteger modulus [read] - the modulus, n
-
BigInteger privateExponent [read] - the private exponent, d
and
-
BigInteger primeP [read] - one of the prime factors of the modulus, p
-
BigInteger primeQ [read] - the other prime factor of the modulus, q
-
BigInteger primeExponentP [read] - d mod (p-1)
-
BigInteger primeExponentQ [read] - d mod (q-1)
-
BigInteger crtCoefficient [read] - q-1 mod p
It does not matter which of p and q is larger.
KeyFactory algorithms
[TODO: DH/ASN.1, DSA/ASN.1, RW/ASN.1, DH/OpenPGP, DSA/OpenPGP, RSA/OpenPGP]
| Generic/ASN.1(transferFormat) | 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.
This factory follows the conventions for encoding of keys in ASN.1
described here.
- 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).
- [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
- Parameters:
-
String transferFormat [creation/read, default "binary"] - one
of the following:
- "binary" indicates that the standard BER binary format is used.
- "base64" indicates that the encoding is an ASCII representation of
the BER data after being converted to base64 format (as specified
in RFC 2045), 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.
- 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:
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,
-- #E(Fq)/n (used only 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
This factory follows the conventions for encoding of keys in ASN.1
described here.
- 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] 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, November 1997 Internet draft.
http://www.pca.dfn.de/eng/team/ske/drafts/draft-ietf-pkix-ipki-ecdsa-00.txt
- Patent status:
- Certicom has patents pending on several techniques for efficient implementation
of elliptic curve arithmetic.
- Hewlett Packard has a patent pending on elliptic curve point compression
[[is this only compression of x coordinates??]].
- 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).
This factory follows the conventions for encoding of keys in ASN.1
described here.
- 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.
- Alias:
- "Elgamal/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 (= gx
where x is secret).
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 and public key algorithm fields SHOULD be
checked for correctness.
- References:
- [Def] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer
"OpenPGP Message Format,"
RFC 2440, November 1998.
- 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 (= gx
where x is secret).
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 and public key algorithm fields SHOULD be
checked for correctness.
- References:
- [Def] Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer
"OpenPGP Message Format,"
RFC 2440, November 1998.
- 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 four-octet number denoting the time that the key was created
(unsigned number of seconds elapsed since midnight, 1 January 1970 UTC).
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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 and
public key algorithm fields SHOULD be checked for correctness.
- 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.
AlgorithmParameterGenerators
[TODO: BBS, DH, DSA, ECDSA]
AlgorithmParameters
[TODO: AlgorithmInfo, ParameterInfo, DH/ASN.1, DSA/ASN.1, ECDSA/ASN.1]
| ECDSA/ASN.1 | AlgorithmParameters
|
- Description:
- The format of a BER or DER-encoded ECParameters object, as defined
in X9.62.
- Aliases:
- "ECParameters", "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).
- Patent status:
- Certicom has patents pending on several techniques for efficient implementation
of elliptic curve arithmetic.
- Hewlett Packard has a patent pending on elliptic curve point compression
[[is this only compression of x coordinates??]].
| RSA/* | AlgorithmParameters
|
- Description:
- This is a "dummy" parameter format, since RSA keys do not require any
cryptographic parameters. However, the parameter object may include a
specification of which algorithms the key can be used with (i.e. the
RSA signature algorithm, and/or the RSA encryption algorithm).
'*' means that any format specifier may be given.
- Description:
- This is a "dummy" parameter format, since RW keys do not require any
cryptographic parameters. However, the parameter object may include a
specification of which algorithms the key can be used with (currently,
only the RW signature algorithm has a standard name).
'*' means that any format specifier may be given.
SecureRandom algorithms
In addition to the names and aliases given below, each provider may choose
to define a default algorithm, for general-purpose use. The class to be used for
this algorithm is declared using a provider property with the key "SecureRandom"
(i.e. with no algorithm name).
Although there is no way to enforce this constraint, choices for default SecureRandom
algorithms should be believed to be at least as conservative as "SHA1PRNG", which was
the default algorithm in JDK 1.1. new SecureRandom() will return the
first default SecureRandom found by searching providers in preference order.
- Description:
- This is the algorithm that was implemented by the SecureRandom class in
JDK 1.1. It is similar (but not identical) to the random number
generator suggested in Annex D of the P1363 standard.
[[need full description]]
- References:
- [Inf] IEEE P1363 (draft),
Standard for Public-Key Cryptography, 1998.
- Designers:
- L. Blum,
Manuel Blum,
M. Shub
- Alias:
- "Blum-Blum-Shub"
- Description:
- [[need to say how to derive x, and how updating of the seed is handled]]
- References:
- [Def] L. Blum, M. Blum, M. Shub,
"A Simple Unpredictable Pseudo-Random Number Generator,"
SIAM Journal on Computing, vol. 15 no. 2,
1996, pp. 364-383.
- [Inf] Bruce Schneier,
"Section 17.9 Complexity-Theoretic Approach to Stream-Cipher Design,"
Applied Cryptography, Second Edition,
John Wiley & Sons, 1996.
- [Inf] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
"Section 5.5.2 Blum-Blum-Shub pseudorandom bit generator,"
Handbook of Applied Cryptography,
CRC Press, 1997.
- Parameters:
-
BigInteger n [write once, no default] - a Blum integer (the
product of two primes, both congruent to 3 mod 4).
- Security comment:
- The security of this PRNG depends on the complexity of factoring
the parameter n.
Trademarks
Cryptix is a trademark of
Systemics Ltd.
Java is a registered trademark of
Sun Microsystems, Inc.
DESX, RC2, RC4, RC5, RC6, MD2, MD4, and MD5 are registered trademarks of
RSA Data Security, Inc., and/or
Security Dynamics Technologies, Inc.
CAST5 and CAST-128 [[and CAST-256?]] are registered trademarks of
Entrust Technologies, Inc.
"Diamond2 Block Cipher" is a trademark of Michael Paul Johnson.
IDEA is a registered trademark of
Ascom Systec Ltd.
Other brand, product, and algorithm names may be trademarks or registered
trademarks of their respective holders.
Author: David Hopwood <hopwood@zetnet.co.uk>
Current maintainer: David Hopwood <hopwood@zetnet.co.uk>
Copyright © 1997-1999 Systemics Ltd
on behalf of the Cryptix Development Team.
All rights reserved.
Cryptix is a trademark of Systemics Ltd.