The naming scheme described here is different from that described in Sun's documentation for the Java Cryptography Architecture. Several name formats have been used up to now for signature algorithms:
All of the algorithms defined here use either modular exponentiation or elliptic curve multiplication, which are potentially vulnerable to timing attacks. See the following paper for details and possible countermeasures:
| DSA[(outputFormat)] | Signature |
The default outputFormat is "DER".
This algorithm is separated from the generalisation, "DSA-1363", described below, in order to ensure that an implementation of DSA by a provider earlier in the priority list does not 'mask' an implementation of DSA-1363.
We explain how to forge public parameters for the Digital Signature Standard with two known messages which always produce the same set of valid signatures (what we call a collision). This attack is thwarted by using the generation algorithm suggested in the specifications of the Standard, so it proves one always need to check proper generation. We also present a similar attack when using this generation algorithm within a complexity 274, which is better than the birthday attack which seeks for collisions on the underlying hash function.
| DSA-1363[(outputFormat)][/encoding] | Signature |
If an encoding method is explicitly specified, it is used instead of the default (this requires that the order of the base in the DSA parameters, usually denoted q, is large enough to accomodate message representatives generated by this encoding method).
This algorithm also differs from the "DSA" algorithm, in having "1363" as the default outputFormat. The "DER" and "OpenPGP" output formats SHOULD normally also be supported.
We explain how to forge public parameters for the Digital Signature Standard with two known messages which always produce the same set of valid signatures (what we call a collision). This attack is thwarted by using the generation algorithm suggested in the specifications of the Standard, so it proves one always need to check proper generation. We also present a similar attack when using this generation algorithm within a complexity 274, which is better than the birthday attack which seeks for collisions on the underlying hash function.These attacks apply to the default encoding method.
| ECDSA[(outputFormat)][/encoding] | Signature |
If an encoding method is explicitly specified, it is used instead of the default (this requires that the order of the base point in the elliptic curve parameters, usually denoted n, is large enough to accomodate message representatives generated by this encoding method).
The default outputFormat is "1363".
| ? ECNR(outputFormat)/encoding | Signature |
| ElgamalSig(outputFormat)/encoding | Signature |
| × ESIGN/encoding | Signature |
| ? NR(outputFormat)/encoding | Signature |
| RSA/encoding | Signature |
| RSA2/encoding | Signature |
This variant of RSA is normally used only with the EMSA2 encoding method, and only for compatibility with ISO/IEC 9796:1991.
| RW/encoding | Signature |
set/getParameter on the Signature object, since there is not
necessarily any object explicitly representing the encoding method.
| EMSA1(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest that is to be used to calculate the message representative.
The only message digest algorithms for which this encoding method is
defined are SHA-1 and RIPEMD-160.
| EMSA2(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest that is to be used to calculate the message representative.
The only message digest algorithms for which this encoding method is
defined are SHA-1 and RIPEMD-160.
| × EMSA5-MGF1(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest to be used. This is used both to calculate the message
representative, and as the underlying digest for MGF1.
| PKCS1-1.5(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest that is to be used to calculate the message representative.
Only message digests for which an ASN.1 OBJECT IDENTIFIER has been defined,
may be used (see comment below).
| MessageDigest | Sequence |
| MD2 | 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 02 05 00 04 10
|
| MD5 | 30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10
|
| SHA-1 | 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
|
| RIPEMD-160 | 30 21 30 09 06 05 2B 24 03 02 01 05 00 04 14
|
| Tiger(24,3) | 30 29 30 0D 06 09 2B 06 01 04 01 DA 47 0C 02 05 00 04 18
|
| SHA-256 | 30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
|
| SHA-384 | 30 41 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 04 30
|
| SHA-512 | 30 51 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
|
An implementation of PKCS1-1.5 encoding MUST allow for at least the message digests listed above to be used (although the same provider need not implement these digests). This is an incompatible change from SCAN 1.0.12-14, where Tiger(24,3) and SHA-{256,384,512} were not required. There was an error in the byte sequence for SHA-1 in SCAN 1.0.12.
| × PSS-MGF1(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest that is to be used by the MGF1 mask generation function.
If PSS is included in an IEEE standard, the University of California will, when that standard is adopted, FREELY license any conforming implementation of PSS as a technique for achieving a digital signature with appendix. No registration fee or other administrative procedure will be required.Note that this is different to the licensing position for PSSR.
| × PSSR-MGF1(digest) | Signature Encoding Method |
String digest [creation, no default] - the name of the
message digest that is to be used by the MGF1 mask generation function.
| ? SSL3 | Signature Encoding Method |
| ? TLS | Signature Encoding Method |
| Raw | Signature Encoding Method |
verify method is called, or an
IllegalArgumentException to be thrown when the
sign method is called.
| 1363 | Output Format |
The convention used by 1363 for formatting more than one arbitrary-length integer, is to concatenate their big-endian unsigned representations. Each integer is padded on the left with zeroes, to the length defined by the algorithm parameters (for example if an integer is in the range 0..n-1, the result will have the same number of bytes as is needed to represent n-1). The signature algorithm is assumed to specify a canonical order for the integers.
To parse this format, the receiver must split it into blocks of the correct lengths (usually equal), one for each integer. If this cannot be done, the signature MUST be treated as invalid.
| DER | Output Format |
The type used to DER-encode more than one arbitrary-length integer, is SEQUENCE { INTEGER a, INTEGER b, ... }. The signature algorithm is assumed to specify a canonical order for the integers.
To parse this format, the receiver must always interpret it as DER, not BER. If the signature is not a DER encoding of the correct type, it MUST be treated as invalid.
| OpenPGP | Output Format |
The convention used by OpenPGP for formatting more than one arbitrary-length integer, is to encode each integer as a two-byte big-endian length field indicating the bit length of the integer, followed by the bytes of the integer in big-endian order, with no leading zeroes (see section 3.2 of RFC 2440). The signature algorithm is assumed to specify a canonical order for the integers.
When parsing this format, if the length fields are inconsistent with the total length of the signature, it MUST be treated as invalid.
|
| Copyright and trademarks |