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, "DSA1363", 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 DSA1363.
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 2^{74}, which is better than the birthday attack which seeks for collisions on the underlying hash function.
DSA1363[(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 2^{74}, 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 SHA1 and RIPEMD160.
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 SHA1 and RIPEMD160.
× EMSA5MGF1(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.
PKCS11.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

SHA1  30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

RIPEMD160  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

SHA256  30 31 30 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20

SHA384  30 41 30 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 04 30

SHA512  30 51 30 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40

An implementation of PKCS11.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.1214, where Tiger(24,3) and SHA{256,384,512} were not required. There was an error in the byte sequence for SHA1 in SCAN 1.0.12.
× PSSMGF1(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.
× PSSRMGF1(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 arbitrarylength integer, is to concatenate their bigendian 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..n1, the result will have the same number of bytes as is needed to represent n1). 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 DERencode more than one arbitrarylength 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 arbitrarylength integer, is to encode each integer as a twobyte bigendian length field indicating the bit length of the integer, followed by the bytes of the integer in bigendian 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 