Usage notes
The usage notes for CSNDDSG.
Notes on formatting the message
- ISO-9796
- The length of the hash must be less than or equal to one-half of the number of bytes required to contain the modulus of the RSA key.
- PKCS-1.0 and PKCS-1.1
- The length of the hash must be 11 bytes shorter than the number of bytes required to contain the
modulus of the RSA key.
When the HASH keyword is specified, the hash must be BER encoded. See Formatting hashes and keys in public-key cryptography for a description of the formatting methods.
- PKCS-PSS
- The first four bytes of the data parameter contain the salt length. For more information on salt length, see Required commands. The remaining bytes of the parameter contains the hash or message.
- X9.31
- There are no restrictions for the hash length or message.
- ZERO-PAD
- The length of the hash must be less than or equal to the number of bytes required to contain the modulus of the RSA key.
- ECDSA
- There are no restrictions for the hash length or message.
- EDDSA and EC-SDSA
- The length of the message must be less than or equal to 8192 bytes.
- CRDL-DSA
- The length of the message must be less than or equal to 5000 bytes with an ML-DSA or CRYSTALS-Dilithium (6,5) private key when on a Crypto
Express7 CCA coprocessor, or less than
or equal to 15000 bytes with an ML-DSA
or CRYSTALS-Dilithium private key when on a
Crypto Express8 and later CCA
coprocessor.
ML-DSA signature generation is non-deterministic by default, with an option for a deterministic mode. The rule group Determinacy Specification may be used to select either deterministic or non-deterministic, with non-deterministic being the default.
For pure ML-DSA (X'05') keys, keywords CRDL-DSA, CRDLHASH, and MESSAGE must be provided.
For pre-hash ML-DSA (X'07') keys, there are two options:- The message is already hashed and you want to sign the hash:
- Provide both the CRDL-DSA and HASH keywords and also provide the hash method keyword that was used to generate the hash.
- The message is un-hashed and you want to hash the message and then sign it:
- Provide both the CRDL-DSA and MESSAGE keywords and also provide the desired hash method.
The RAWSEED rule requires the PKA Key Generate - Permit Regeneration Data access control point.
PKCS-PSS details
Before specifying PKCS-PSS, see section A.2.3 of RFC 8017: PKCS #1: RSA
Cryptography Specifications Version 2.2 (PKCS #1: RSA Cryptography Specifications Version 2.2). Section
A.2.3 defines a parameter field for RSASSA-PSS that has the following four parameters:
- hashAlgorithm
- This parameter identifies the hash function. A hashing-method specification keyword of SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 is required. There is no default.
- maskGenAlgorithm
- This parameter identifies the mask generation function. MGF1 is a mask generation function based on a hash function and is the only function currently defined by the standard. For CCA, the hash function on which MGF1 is based is always the same as hashAlgorithm. Although this is not required, CCA enforces the recommendation by the standard that the underlying hash function be the same as the one identified by hashAlgorithm.
- saltLength
- This is the length of the salt, which is a randomly generated value. Use the data variable of the verb to prepend a 4-byte saltLength parameter in big endian format to the hash digest to be signed or the message to be hashed and signed.
- trailerField
- This is the trailer field number. This is not an input to the verb because it is always set to the value X'BC'. Other trailer field numbers are not supported by the standard.