Cryptographic Token Interface Standard

PKCS#11

Mechanisms

A mechanism specifies precisely how a certain cryptographic process is to be performed.

The following table shows which Cryptoki mechanisms are supported by different cryptographic operations. For any particular token, of course, a particular operation may well support only a subset of the mechanisms listed. There is also no guarantee that a token which supports one mechanism for some operation supports any other mechanism for any other operation (or even supports that same mechanism for any other operation). For example, even if a token is able to create RSA digital signatures with the CKM_RSA_PKCS mechanism, it may or may not be the case that the same token can also perform RSA encryption.

Table 10-1, Mechanisms vs. Functions
Functions

Mechanism Encrypt & Decrypt Sign & Verify SR & VR ¹ Digest Gen. Key/ Key Pair Wrap & Unwrap Derive

CKM_RSA_PKCS_KEY_PAIR_GEN X

CKM_RSA_PKCS X² X² X X

CKM_RSA_9796 X² X

CKM_RSA_X_509 X² X² X X

CKM_MD2_RSA_PKCS X X

CKM_MD5_RSA_PKCS X X

CKM_SHA1_RSA_PKCS X X

CKM_DSA_KEY_PAIR_GEN X

CKM_DSA X²

CKM_DSA_SHA1 X

CKM_FORTEZZA_TIMESTAMP X²

CKM_ECDSA_KEY_PAIR_GEN X

CKM_ECDSA X²

CKM_ECDSA_SHA1 X

CKM_DH_PKCS_KEY_PAIR_GEN X

CKM_DH_PKCS_DERIVE X

CKM_KEA_KEY_PAIR_GEN X

CKM_KEA_KEY_DERIVE X

CKM_MAYFLY_KEY_PAIR_GEN X

CKM_MAYFLY_KEY_DERIVE X

CKM_GENERIC_SECRET_KEY_GEN X

CKM_RC2_KEY_GEN X

CKM_RC2_ECB X X

CKM_RC2_CBC X X

CKM_RC2_CBC_PAD X X

CKM_RC2_MAC_GENERAL X

CKM_RC2_MAC X

CKM_RC4_KEY_GEN X

CKM_RC4 X

CKM_RC5_KEY_GEN X

CKM_RC5_ECB X X

CKM_RC5_CBC X X

CKM_RC5_CBC_PAD X X

CKM_RC5_MAC_GENERAL X

CKM_RC5_MAC X

CKM_DES_KEY_GEN X

CKM_DES_ECB X X

CKM_DES_CBC X X

CKM_DES_CBC_PAD X X

CKM_DES_MAC_GENERAL X

CKM_DES_MAC X

CKM_DES2_KEY_GEN X

CKM_DES3_KEY_GEN X

CKM_DES3_ECB X X

CKM_DES3_CBC X X

CKM_DES3_CBC_PAD X X

CKM_DES3_MAC_GENERAL X

CKM_DES3_MAC X

CKM_CAST_KEY_GEN X

CKM_CAST_ECB X X

CKM_CAST_CBC X X

CKM_CAST_CBC_PAD X X

CKM_CAST_MAC_GENERAL X

CKM_CAST_MAC X

CKM_CAST3_KEY_GEN X

CKM_CAST3_ECB X X

CKM_CAST3_CBC X X

CKM_CAST3_CBC_PAD X X

CKM_CAST3_MAC_GENERAL X

CKM_CAST3_MAC X

CKM_CAST5_KEY_GEN X

CKM_CAST5_ECB X X

CKM_CAST5_CBC X X

CKM_CAST5_CBC_PAD X X

CKM_CAST5_MAC_GENERAL X

CKM_CAST5_MAC X

CKM_IDEA_KEY_GEN X

CKM_IDEA_ECB X X

CKM_IDEA_CBC X X

CKM_IDEA_CBC_PAD X X

CKM_IDEA_MAC_GENERAL X

CKM_IDEA_MAC X

CKM_CDMF_KEY_GEN X

CKM_CDMF_ECB X X

CKM_CDMF_CBC X X

CKM_CDMF_CBC_PAD X X

CKM_CDMF_MAC_GENERAL X

CKM_CDMF_MAC X

CKM_SKIPJACK_KEY_GEN X

CKM_SKIPJACK_ECB64 X

CKM_SKIPJACK_CBC64 X

CKM_SKIPJACK_OFB64 X

CKM_SKIPJACK_CFB64 X

CKM_SKIPJACK_CFB32 X

CKM_SKIPJACK_CFB16 X

CKM_SKIPJACK_CFB8 X

CKM_SKIPJACK_WRAP X

CKM_SKIPJACK_PRIVATE_WRAP X

CKM_SKIPJACK_RELAYX X³

CKM_BATON_KEY_GEN X

CKM_BATON_ECB128 X

CKM_BATON_ECB96 X

CKM_BATON_CBC128 X

CKM_BATON_COUNTER X

CKM_BATON_SHUFFLE X

CKM_BATON_WRAP X

CKM_JUNIPER_KEY_GEN X

CKM_JUNIPER_ECB128 X

CKM_JUNIPER_CBC128 X

CKM_JUNIPER_COUNTER X

CKM_JUNIPER_SHUFFLE X

CKM_JUNIPER_WRAP X

CKM_MD2 X

CKM_MD2_HMAC_GENERAL X

CKM_MD2_HMAC X

CKM_MD2_KEY_DERIVATION X

CKM_MD5 X

CKM_MD5_HMAC_GENERAL X

CKM_MD5_HMAC X

CKM_MD5_KEY_DERIVATION X

CKM_SHA_1 X

CKM_SHA_1_HMAC_GENERAL X

CKM_SHA_1_HMAC X

CKM_SHA1_KEY_DERIVATION X

CKM_FASTHASH X

CKM_PBE_MD2_DES_CBC X

CKM_PBE_MD5_DES_CBC X

CKM_PBE_MD5_CAST_CBC X

CKM_PBE_MD5_CAST3_CBC X

CKM_PBE_MD5_CAST5_CBC X

CKM_KEY_WRAP_SET_OAEP X

CKM_KEY_WRAP_LYNKS X

CKM_SSL3_PRE_MASTER_KEY_GEN X

CKM_SSL3_MASTER_KEY_DERIVE X

CKM_SSL3_KEY_AND_MAC_DERIVE X

CKM_SSL3_MD5_MAC X

CKM_SSL3_SHA1_MAC X

CKM_CONCATENATE_BASE_AND_KEY X

CKM_CONCATENATE_BASE_AND_DATA X

CKM_CONCATENATE_DATA_AND_BASE X

CKM_XOR_BASE_AND_DATA X

CKM_EXTRACT_KEY_FROM_KEY X

¹ SR = SignRecover, VR = VerifyRecover.

² Single-part operations only.

³ Mechanism can only be used for wrapping, not unwrapping.

The remainder of Section will present in detail the mechanisms supported by Cryptoki v2.0 and the parameters which are supplied to them.

In general, if a mechanism makes no mention of the ulMinKeyLen and ulMaxKeyLen fields of the CK_MECHANISM_INFO structure, then those fields have no meaning for that particular mechanism.

RSA mechanisms

PKCS #1 RSA key pair generation

The PKCS #1 RSA key pair generation mechanism, denoted CKM_RSA_PKCS_KEY_PAIR_GEN, is a key pair generation mechanism based on the RSA public-key cryptosystem, as defined in PKCS #1.

It does not have a parameter.

The mechanism generates RSA public/private key pairs with a particular modulus length in bits and public exponent, as specified in the CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT attributes of the template for the public key.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, CKA_MODULUS, and CKA_PUBLIC_EXPONENT attributes to the new public key. It contributes the CKA_CLASS and CKA_KEY_TYPE attributes to the new private key; it may also contribute some of the following attributes to the new private key: CKA_MODULUS, CKA_PUBLIC_EXPONENT, CKA_PRIVATE_EXPONENT, CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2, CKA_COEFFICIENT (see Section). Other attributes supported by the RSA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values.

Keys generated with this mechanism can be used with the following mechanisms: PKCS #1 RSA; ISO/IEC 9796 RSA; X.509 (raw) RSA; PKCS #1 RSA with MD2; PKCS #1 RSA with MD5; PKCS #1 RSA with SHA-1; and OAEP key wrapping for SET.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RSA modulus sizes, in bits.

PKCS #1 RSA

The PKCS #1 RSA mechanism, denoted CKM_RSA_PKCS, is a multi-purpose mechanism based on the RSA public-key cryptosystem and the block formats defined in PKCS #1. It supports single-part encryption and decryption; single-part signatures and verification with and without message recovery; key wrapping; and key unwrapping. This mechanism corresponds only to the part of PKCS #1 that involves RSA; it does not compute a message digest or a DigestInfo encoding as specified for the md2withRSAEncryption and md5withRSAEncryption algorithms in PKCS #1.

This mechanism does not have a parameter.

This mechanism can wrap and unwrap any secret key of appropriate length. Of course, a particular token may not be able to wrap/unwrap every appropriate-length secret key that it supports. For wrapping, the "input" to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type or any other information about the key, except the key length; the application must convey these separately. In particular, the mechanism contributes only the CKA_CLASS and CKA_VALUE (and CKA_VALUE_LEN, if the key has it) attributes to the recovered key during unwrapping; other attributes must be specified in the template.

Constraints on key types and the length of the data are summarized in the following table. For encryption, decryption, signatures and signature verification, the input and output data may begin at the same location in memory. In the table, k is the length in bytes of the RSA modulus.

Table 10-2, PKCS #1 RSA: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt¹ RSA public key <= k -11 k block type 02

C_Decrypt¹ RSA private key k <= k -11 block type 02

C_Sign¹ RSA private key <= k -11 k block type 01

C_SignRecover RSA private key <= k -11 k block type 01

C_Verify¹ RSA public key <= k -11, k ² N/A block type 01

C_VerifyRecover RSA public key k <= k -11 block type 01

C_WrapKey RSA public key <= k -11 k block type 02

C_UnwrapKey RSA private key k <= k -11 block type 02

¹ Single-part operations only.

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RSA modulus sizes, in bits.

ISO/IEC 9796 RSA

The ISO/IEC 9796 RSA mechanism, denoted CKM_RSA_9796, is a mechanism for single-part signatures and verification with and without message recovery based on the RSA public-key cryptosystem and the block formats defined in ISO/IEC 9796 and its annex A. This mechanism is compatible with the draft ANSI X9.31 (assuming the length in bits of the X9.31 hash value is a multiple of 8).

This mechanism processes only byte strings, whereas ISO/IEC 9796 operates on bit strings. Accordingly, the following transformations are performed:

Data is converted between byte and bit string formats by interpreting the most-significant bit of the leading byte of the byte string as the leftmost bit of the bit string, and the least-significant bit of the trailing byte of the byte string as the rightmost bit of the bit string (this assumes the length in bits of the data is a multiple of 8).
A signature is converted from a bit string to a byte string by padding the bit string on the left with 0 to 7 zero bits so that the resulting length in bits is a multiple of 8, and converting the resulting bit string as above; it is converted from a byte string to a bit string by converting the byte string as above, and removing bits from the left so that the resulting length in bits is the same as that of the RSA modulus. This mechanism does not have a parameter.

Constraints on key types and the length of input and output data are summarized in the following table. In the table, k is the length in bytes of the RSA modulus.

Table 10-3, ISO/IEC 9796 RSA: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign¹ RSA private key <= LOWER(k /2) k

C_SignRecover RSA private key <= LOWER(k /2) k

C_Verify¹ RSA public key <= LOWER(k /2), k ² N/A

C_VerifyRecover RSA public key k <= LOWER(k /2)

¹ Single-part operations only.

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RSA modulus sizes, in bits.

X.509 (raw) RSA

The X.509 (raw) RSA mechanism, denoted CKM_RSA_X_509, is a multi-purpose mechanism based on the RSA public-key cryptosystem. It supports single-part encryption and decryption; single-part signatures and verification with and without message recovery; key wrapping; and key unwrapping. All these operations are based on so-called "raw" RSA, as assumed in X.509.

"Raw" RSA as defined here encrypts a byte string by converting it to an integer, most-significant byte first, applying "raw" RSA exponentiation, and converting the result to a byte string, most-significant byte first. The input string, considered as an integer, must be less than the modulus; the output string is also less than the modulus.

This mechanism does not have a parameter.

This mechanism can wrap and unwrap any secret key of appropriate length. Of course, a particular token may not be able to wrap/unwrap every appropriate-length secret key that it supports. For wrapping, the "input" to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type, key length, or any other information about the key; the application must convey these separately, and supply them when unwrapping the key.

Unfortunately, X.509 does not specify how to perform padding for RSA encryption. For this mechanism, padding should be performed by prepending plaintext data with 0 bytes. In effect, to encrypt the sequence of plaintext bytes b₁ b₂ ... b_n (n <= k), Cryptoki forms P=2^n-1b₁+2^n-2b₂+...+b_n. This number must be less than the RSA modulus. The k -byte ciphertext (k is the length in bytes of the RSA modulus) is produced by raising P to the RSA public exponent modulo the RSA modulus. Decryption of a k -byte ciphertext C is accomplished by raising C to the RSA private exponent modulo the RSA modulus, and returning the resulting value as a sequence of exactly k bytes. If the resulting plaintext is to be used to produce an unwrapped key, then however many bytes are specified in the template for the length of the key are taken from the end of this sequence of bytes.

Technically, the above procedures may differ very slightly from certain details of what is specified in X.509.

Executing cryptographic operations using this mechanism can result in the error returns CKR_DATA_INVALID (if plaintext is supplied which has the same length as the RSA modulus and is numerically at least as large as the modulus) and CKR_ENCRYPTED_DATA_INVALID (if ciphertext is supplied which has the same length as the RSA modulus and is numerically at least as large as the modulus).

Constraints on key types and the length of input and output data are summarized in the following table. In the table, k is the length in bytes of the RSA modulus.

Table 10-4, X.509 (Raw) RSA: Key And Data Length Constraints
Function Key type Input length Output length

C_Encrypt¹ RSA public key <= k k

C_Decrypt¹ RSA private key k k

C_Sign¹ RSA private key <= k k

C_SignRecover RSA private key <= k k

C_Verify¹ RSA public key <= k, k ² N/A

C_VerifyRecover RSA public key k k

C_WrapKey RSA public key <= k k

C_UnwrapKey RSA private key k <= k (specified in template)

¹ Single-part operations only.

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RSA modulus sizes, in bits.

This mechanism is intended for compatibility with applications that do not follow the PKCS #1 or ISO/IEC 9796 block formats.

PKCS #1 RSA signature with MD2, MD5, or SHA-1

The PKCS #1 RSA signature with MD2 mechanism, denoted CKM_MD2_RSA_PKCS, performs single- and multiple-part digital signatures and verification operations without message recovery. The operations performed are as described in PKCS #1 with the object identifier md2WithRSAEncryption.

Similarly, the PKCS #1 RSA signature with MD5 mechanism, denoted CKM_MD5_RSA_PKCS, performs the same operations described in PKCS #1 with the object identifier md5WithRSAEncryption. The PKCS #1 RSA signature with SHA-1 mechanism, denoted CKM_SHA1_RSA_PKCS, performs the same operations, except that it uses the hash function SHA-1, instead of MD2 or MD5.

None of these mechanisms has a parameter.

Constraints on key types and the length of the data for these mechanisms are summarized in the following table. In the table, k is the length in bytes of the RSA modulus. For the PKCS #1 RSA signature with MD2 and PKCS #1 RSA signature with MD5 mechanisms, k must be at least 27; for the PKCS #1 RSA signature with SHA-1 mechanism, k must be at least 31.

Table 10-5, PKCS #1 RSA Signatures with MD2, MD5, or SHA-1: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Sign RSA private key any k block type 01

C_Verify RSA public key any, k ² N/A block type 01

² Data length, signature length.

For these mechanisms, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RSA modulus sizes, in bits.

DSA mechanisms

DSA key pair generation

The DSA key pair generation mechanism, denoted CKM_DSA_KEY_PAIR_GEN, is a key pair generation mechanism based on the Digital Signature Algorithm defined in FIPS PUB 186.

This mechanism does not have a parameter.

The mechanism generates DSA public/private key pairs with a particular prime, subprime and base, as specified in the CKA_PRIME, CKA_SUBPRIME, and CKA_BASE attributes of the template for the public key. Note that this version of Cryptoki does not include a mechanism for generating these DSA parameters.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_SUBPRIME, CKA_BASE, and CKA_VALUE attributes to the new private key. Other attributes supported by the DSA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of DSA prime sizes, in bits.

DSA

The DSA mechanism, denoted CKM_DSA, is a mechanism for single-part signatures and verification based on the Digital Signature Algorithm defined in FIPS PUB 186. (This mechanism corresponds only to the part of DSA that processes the 20-byte hash value; it does not compute the hash value.)

For the purposes of this mechanism, a DSA signature is a 40-byte string, corresponding to the concatenation of the DSA values r and s, each represented most-significant byte first.

It does not have a parameter.

Constraints on key types and the length of data are summarized in the following table:

Table 10-6, DSA: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign¹ DSA private key 20 40

C_Verify¹ DSA public key 20, 40² N/A

¹ Single-part operations only.

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of DSA prime sizes, in bits.

DSA with SHA-1

The DSA with SHA-1 mechanism, denoted CKM_DSA_SHA1, is a mechanism for single- and multiple-part signatures and verification based on the Digital Signature Algorithm defined in FIPS PUB 186. This mechanism computes the entire DSA specification, including the hashing with SHA-1.

For the purposes of this mechanism, a DSA signature is a 40-byte string, corresponding to the concatenation of the DSA values r and s, each represented most-significant byte first.

This mechanism does not have a parameter.

Constraints on key types and the length of data are summarized in the following table:

Table 10-7, DSA with SHA-1: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign DSA private key any 40

C_Verify DSA public key any, 40² N/A

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of DSA prime sizes, in bits.

FORTEZZA timestamp

The FORTEZZA timestamp mechanism, denoted CKM_FORTEZZA_TIMESTAMP, is a mechanism for single-part signatures and verification. The signatures it produces and verifies are DSA digital signatures over the provided hash value and the current time.

It has no parameters.

Constraints on key types and the length of data are summarized in the following table. The input and output data may begin at the same location in memory.

Table 10-8, FORTEZZA timestamp: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign¹ DSA private key 20 40

C_Verify¹ DSA public key 20, 40² N/A

¹ Single-part operations only.

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of DSA prime sizes, in bits.

ECDSA mechanisms

ECDSA key pair generation

The ECDSA key pair generation mechanism, denoted CKM_DSA_KEY_PAIR_GEN, is a key pair generation mechanism based on the Elliptic Curve Digital Signature Algorithm defined in IEEE P1363.

This mechanism does not have a parameter.

The mechanism generates ECDSA public/private key pairs with a particular prime, subprime and base, as specified in the CKA_PRIME, CKA_SUBPRIME, and CKA_BASE attributes of the template for the public key. Note that this version of Cryptoki does not include a mechanism for generating these ECDSA parameters.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_SUBPRIME, CKA_BASE, and CKA_VALUE attributes to the new private key. Other attributes supported by the ECDSA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of ECDSA prime sizes, in bits.

ECDSA

The ECDSA mechanism, denoted CKM_ECDSA, is a mechanism for single-part signatures and verification based on the Elliptic Curve Digital Signature Algorithm defined in IEEE P1363. (This mechanism corresponds only to the part of ECDSA that processes the 20-byte hash value; it does not compute the hash value.)

For the purposes of this mechanism, an ECDSA signature is a 40-byte string, corresponding to the concatenation of the ECDSA values r and s, each represented most-significant byte first.

This mechanism does not have a parameter.

Constraints on key types and the length of data are summarized in the following table:

Table 10-9, ECDSA: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign¹ ECDSA private key 20 40

C_Verify¹ ECDSA public key 20, 40² N/A

¹ Single-part operations only.

²Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of ECDSA prime sizes, in bits.

ECDSA with SHA-1

The ECDSA with SHA-1 mechanism, denoted CKM_ECDSA_SHA1, is a mechanism for single- and multiple-part signatures and verification based on the Elliptic Curve Digital Signature Algorithm defined in IEEE P1363. This mechanism computes the entire ECDSA specification, including the hashing with SHA-1.

For the purposes of this mechanism, a ECDSA signature is a 40-byte string, corresponding to the concatenation of the ECDSA values r and s, each represented most-significant byte first.

This mechanism does not have a parameter.

Constraints on key types and the length of data are summarized in the following table:

Table 10-10, ECDSA with SHA-1: Key And Data Length Constraints
Function Key type Input length Output length

C_Sign ECDSA private key any 40

C_Verify ECDSA public key any, 40² N/A

² Data length, signature length.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of ECDSA prime sizes, in bits.

Diffie-Hellman mechanisms

PKCS #3 Diffie-Hellman key pair generation

The PKCS #3 Diffie-Hellman key pair generation mechanism, denoted CKM_DH_PKCS_KEY_PAIR_GEN, is a key pair generation mechanism based on Diffie-Hellman key agreement, as defined in PKCS #3. (This is analogous to what PKCS #3 calls "phase I".)

It does not have a parameter.

The mechanism generates Diffie-Hellman public/private key pairs with a particular prime and base, as specified in the CKA_PRIME and CKA_BASE attributes of the template for the public key. If the CKA_VALUE_BITS attribute of the private key is specified, the mechanism limits the length in bits of the private value, as described in PKCS #3. Note that this version of Cryptoki does not include a mechanism for generating a prime and base.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_BASE, and CKA_VALUE (and the CKA_VALUE_BITS attribute, if it is not already provided in the template) attributes to the new private key; other attributes required by the Diffie-Hellman public and private key types must be specified in the templates.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of Diffie-Hellman prime sizes, in bits.

PKCS #3 Diffie-Hellman key derivation

The PKCS #3 Diffie-Hellman key derivation mechanism, denoted CKM_DH_PKCS_DERIVE, is a mechanism for key derivation based on Diffie-Hellman key agreement, as defined in PKCS #3. (This is analogous to what PKCS #3 calls "phase II".)

It has a parameter, which is the public value of the other party in the key agreement protocol, represented as a Cryptoki "Big integer" (i.e., a sequence of bytes, most-significant byte first).

This mechanism derives a secret key from a Diffie-Hellman private key and the public value of the other party. It computes a Diffie-Hellman secret value from the public value and private key according to PKCS #3, and truncates the result according to the CKA_KEY_TYPE attribute of the template and, if it has one and the key type supports it, the CKA_VALUE_LEN attribute of the template. (The truncation removes bytes from the leading end of the secret value.) The mechanism contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key type must be specified in the template.

The derived key inherits the values of the CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE, and CKA_NEVER_EXTRACTABLE attributes from the base key. The values of the CKA_SENSITIVE and CKA_EXTRACTABLE attributes may be overridden in the template for the derived key, however. Of course, if the base key has the CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the template may not specify that the derived key should have the CKA_SENSITIVE attribute set to FALSE; similarly, if the base key has the CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the template may not specify that the derived key should have the CKA_EXTRACTABLE attribute set to TRUE.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of Diffie-Hellman prime sizes, in bits.

KEA mechanism parameters

CK_KEA_DERIVE_PARAMS

CK_KEA_DERIVE_PARAMS is a structure that provides the parameters to the CKM_KEA_DERIVE mechanism. It is defined as follows:

typedef struct CK_KEA_DERIVE_PARAMS {
CK_BBOOL isSender;
CK_ULONG ulRandomLen;
CK_BYTE_PTR pRandomA;
CK_BYTE_PTR pRandomB;
CK_ULONG ulPublicDataLen;
CK_BYTE_PTR pPublicData;
} CK_KEA_DERIVE;

isSender Option for generating the key (called a TEK). The value is TRUE if the sender (originator) generates the TEK, FALSE if the recipient is regenerating the TEK.

ulRandomLen size of random Ra and Rb, in bytes

pRandomA pointer to Ra data

pRandomB pointer to Rb data

ulPublicDataLen other party's KEA public key size

pPublicData pointer to other party's KEA public key value
CK_KEA_DERIVE_PARAMS_PTR

CK_KEA_DERIVE_PARAMS_PTR points to a CK_KEA_DERIVE_PARAMS structure. It is implementation-dependent.

KEA mechanisms

KEA key pair generation

The KEA key pair generation mechanism, denoted CKM_KEA_KEY_PAIR_GEN, is a key pair generation mechanism

It does not have a parameter.

The mechanism generates KEA public/private key pairs with a particular prime, subprime and base, as specified in the CKA_PRIME, CKA_SUBPRIME, and CKA_BASE attributes of the template for the public key. Note that this version of Cryptoki does not include a mechanism for generating these KEA parameters.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE and CKA_VALUE attributes to the new public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_SUBPRIME, CKA_BASE, and CKA_VALUE attributes to the new private key. Other attributes supported by the KEA public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of KEA prime sizes, in bits.

KEA key derivation

The KEA key derivation mechanism, denoted CKM_KEA_DERIVE, is a mechanism for key derivation based on KEA, the Key Exchange Algorithm.

It has a parameter, a CK_KEA_DERIVE_PARAMS structure.

This mechanism derives a secret value, and truncates the result according to the CKA_KEY_TYPE attribute of the template and, if it has one and the key type supports it, the CKA_VALUE_LEN attribute of the template. (The truncation removes bytes from the leading end of the secret value.) The mechanism contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key type must be specified in the template.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of KEA prime sizes, in bits.

MAYFLY mechanism parameters

CK_MAYFLY_DERIVE_PARAMS

CK_MAYFLY_DERIVE_PARAMS is a structure that provides the parameters to the CKM_MAYFLY_DERIVE mechanism. It is defined as follows:

typedef struct CK_MAYFLY_DERIVE_PARAMS {
CK_BBOOL isSender;
CK_ULONG ulRandomLen;
CK_BYTE_PTR pRandomA;
CK_BYTE_PTR pRandomB;
CK_ULONG ulPublicDataLen;
CK_BYTE_PTR pPublicData;
} CK_MAYFLY_DERIVE;

isSender Option for generating the key (called a TEK). The value is TRUE if the sender (originator) generates the TEK, FALSE if the recipient is regenerating the TEK.

ulRandomLen size of random Ra and Rb, in bytes

pRandomA pointer to Ra data

pRandomB pointer to Rb data

ulPublicDataLen other party's MAYFLY public key size

pPublicData pointer to other party's MAYFLY public key value
CK_MAYFLY_DERIVE_PARAMS_PTR

CK_MAYFLY_DERIVE_PARAMS_PTR points to a CK_MAYFLY_DERIVE_PARAMS structure. It is implementation-dependent.

MAYFLY mechanisms

MAYFLY key pair generation

The MAYFLY key pair generation mechanism, called CKM_KEA_KEY_PAIR_GEN, is a key pair generation mechanism for the MAYFLY key exchange key pair.

It does not have a parameter.

The mechanism generates MAYFLY public/private key pairs with a particular prime, subprime and base, as specified in the CKA_PRIME, CKA_SUBPRIME, and CKA_BASE attributes of the template for the public key. Note that this version of Cryptoki does not include a mechanism for generating these MAYFLY parameters.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_SUBPRIME, CKA_BASE, and CKA_VALUE attributes to the new private key. Other attributes supported by the MAYFLY public and private key types (specifically, the flags indicating which functions the keys support) may also be specified in the templates for the keys or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of MAYFLY prime sizes, in bits.

MAYFLY key derivation

The MAYFLY key derivation mechanism, denoted CKM_MAYFLY_DERIVE, is a mechanism for key derivation based on MAYFLY.

It has a parameter, a CK_MAYFLY_DERIVE_PARAMS structure.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of MAYFLY prime sizes, in bits.

Generic secret key mechanisms

Generic secret key generation

The generic secret key generation mechanism, denoted CKM_GENERIC_SECRET_KEY_GEN, is used to generate generic secret keys. The generated keys take on any attributes provided in the template passed to the C_GenerateKey call, and the CKA_VALUE_LEN attribute specifies the length of the key to be generated.

It does not have a parameter.

The template supplied must specify a value for the CKA_VALUE_LEN attribute. If the template specifies an object type and a class, they must have the following values:

CK_OBJECT_CLASS = CKO_SECRET_KEY;
CK_KEY_TYPE = CKK_GENERIC_SECRET;

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of key sizes, in bits.

Wrapping/unwrapping private keys (RSA, Diffie-Hellman, and DSA)

Cryptoki v2.0 allows the use of secret keys for wrapping and unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type. PKCS #8 requires an algorithm identifier for the type of the secret key. The object identifiers for the needed algorithm identifiers are as follows:

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
dhKeyAgreement OBJECT IDENTIFIER ::= { pkcs-3 1}
DSA OBJECT IDENTIFIER ::= { iso(1) identifier-organization(3) oiw(14) secsig(3) algorithm(2) 12 }

where

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1 }
pkcs-3 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 }

These object identifiers have the following parameters, respectively:

NULL
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER, -- g
privateValueLength INTEGER OPTIONAL
}
DSAParameters ::= SEQUENCE {
modulusLength INTEGER, -- length of p in bits
prime1 INTEGER, -- modulus p
prime2 INTEGER, -- modulus q
base INTEGER -- base g
}

Within the PrivateKeyInfo type:

RSA private keys are BER-encoded according to PKCS #1's RSAPrivateKey ASN.1 type. This type requires particular values for all the attributes specific to Cryptoki's RSA private key objects. In other words, if a Cryptoki library does not have values for an RSA private key's CKA_MODULUS, CKA_PUBLIC_EXPONENT, CKA_PRIVATE_EXPONENT, CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT2, and CKA_COEFFICIENT values, it cannot create an RSAPrivateKey BER-encoding of the key, and so it cannot prepare it for wrapping.

* Diffie-Hellman private keys are encoded by expressing the private value as a sequence of bytes, most-significant byte first, and then BER-encoding that sequence of bytes as an OCTET STRING.
* DSA private keys are encoded by expressing the private value as a sequence of of bytes, most-significant byte first, and then BER-encoding that sequence of bytes as an OCTET STRING.

Once a private key has been BER-encoded as a PrivateKeyInfo type, the resulting string of bytes can be encrypted with the secret key. This encryption must be done in CBC mode with PKCS padding.

Unwrapping a wrapped private key undoes the above procedure. The CBC-encrypted ciphertext is decrypted, and the PKCS padding is removed. The data thereby obtained are parsed as a PrivateKeyInfo type, and the wrapped key is produced. An error will result if the original wrapped key does not decrypt properly, or if the decrypted unpadded data does not parse properly, or its type does not match the key type specified in the template for the new key. The unwrapping mechanism contributes only those attributes specified in the PrivateKeyInfo type to the newly-unwrapped key; other attributes must be specified in the template, or will take their default values.

The RC2 cipher

RC2 is a proprietary block cipher which is trademarked by RSA Data Security. It has a variable keysize and an additional parameter, the "effective number of bits in the RC2 search space", which can take on values in the range 1-1024, inclusive.

RC2 mechanism parameters

CK_RC2_PARAMS

CK_RC2_PARAMS provides the parameters to the CKM_RC2_ECB and CKM_RC2_MAC mechanisms. It holds the effective number of bits in the RC2 search space. It is defined as follows:

typdef CK_ULONG CK_RC2_PARAMS;

CK_RC2_PARAMS_PTR

CK_RC2_PARAMS_PTR points to a CK_RC2_PARAMS structure. It is implementation-dependent.

CK_RC2_CBC_PARAMS

CK_RC2_CBC_PARAMS is a structure that provides the parameters to the CKM_RC2_CBC and CKM_RC2_CBC_PAD mechanisms. It is defined as follows:

typedef struct CK_RC2_CBC_PARAMS {
CK_ULONG ulEffectiveBits;
CK_BYTE iv[8];
} CK_RC2_CBC_PARAMS;

ulEffectiveBits the effective number of bits in the RC2 search space

iv the initialization vector (IV) for cipher block chaining mode
CK_RC2_CBC_PARAMS_PTR

CK_RC2_CBC_PARAMS_PTR points to a CK_RC2_CBC_PARAMS structure. It is implementation-dependent.

CK_RC2_MAC_GENERAL_PARAMS

CK_RC2_MAC_GENERAL_PARAMS is a structure that provides the parameters to the CKM_RC2_MAC_GENERAL mechanism. It is defined as follows:

typedef struct CK_RC2_MAC_GENERAL_PARAMS {
CK_ULONG ulEffectiveBits;
CK_ULONG ulMacLength;
} CK_RC2_MAC_GENERAL_PARAMS;

ulEffectiveBits the effective number of bits in the RC2 search space

ulMacLength length of the MAC produced, in bytes
CK_RC2_MAC_GENERAL_PARAMS_PTR

CK_RC2_MAC_GENERAL_PARAMS_PTR points to a CK_RC2_MAC_GENERAL_PARAMS structure. It is implementation-dependent.

RC2 mechanisms

RC2 key generation

The RC2 key generation mechanism, denoted CKM_RC2_KEY_GEN, is a key generation mechanism for RSA Data Security's proprietary block cipher RC2.

It does not have a parameter.

The mechanism generates RC2 keys with a particular length in bytes, as specified in the CKA_VALUE_LEN attribute of the template for the key.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key. Other attributes supported by the RC2 key type (specifically, the flags indicating which functions the key supports) may be specified in the template for the key, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 key sizes, in bits.

RC2-ECB

RC2-ECB, denoted CKM_RC2_ECB, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's proprietary block cipher RC2 and electronic codebook mode as defined in FIPS PUB 81.

It has a parameter, a CK_RC2_PARAMS, which indicates the effective number of bits in the RC2 search space.

This mechanism can wrap and unwrap any secret key. Of course, a particular token may not be able to wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with up to seven null bytes so that the resulting length is a multiple of eight. The output data is the same length as the padded input data. It does not wrap the key type, key length, or any other information about the key; the application must convey these separately.

For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the CKA_KEY_TYPE attribute of the template and, if it has one, and the key type supports it, the CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key type must be specified in the template.

Constraints on key types and the length of data are summarized in the following table:

Table 10-11, RC2-ECB: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt RC2 multiple of 8 same as input length no final part

C_Decrypt RC2 multiple of 8 same as input length no final part

C_WrapKey RC2 any input length rounded up to multiple of 8

C_UnwrapKey RC2 multiple of 8 determined by type of key being unwrapped or CKA_VALUE_LEN

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 effective number of bits.

RC2-CBC

RC2-CBC, denoted CKM_RC2_CBC, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's proprietary block cipher RC2 and cipher-block chaining mode as defined in FIPS PUB 81.

It has a parameter, a CK_RC2_CBC_PARAMS structure, where the first field indicates the effective number of bits in the RC2 search space, and the next field is the initialization vector for cipher block chaining mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-12, RC2-CBC: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt RC2 multiple of 8 same as input length no final part

C_Decrypt RC2 multiple of 8 same as input length no final part

C_WrapKey RC2 any input length rounded up to multiple of 8

C_UnwrapKey RC2 multiple of 8 determined by type of key being unwrapped or CKA_VALUE_LEN

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 effective number of bits.

RC2-CBC with PKCS padding

RC2-CBC with PKCS padding, denoted CKM_RC2_CBC_PAD, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's proprietary block cipher RC2; cipher-block chaining mode as defined in FIPS PUB 81; and the block cipher padding method detailed in PKCS #7.

It has a parameter, a CK_RC2_CBC_PARAMS structure, where the first field indicates the effective number of bits in the RC2 search space, and the next field is the initialization vector.

The PKCS padding in this mechanism allows the length of the plaintext value to be recovered from the ciphertext value. Therefore, when unwrapping keys with this mechanism, no value should be specified for the CKA_VALUE_LEN attribute.

In addition to being able to wrap and unwrap secret keys, this mechanism can wrap and unwrap RSA, Diffie-Hellman, and DSA private keys (see Section for details). The entries in Table 10 -13 for data length constraints when wrapping and unwrapping keys do not apply to wrapping and unwrapping private keys.

Constraints on key types and the length of data are summarized in the following table:

Table 10-13, RC2-CBC with PKCS padding: Key And Data Length Constraints
Function Key type Input length Output length

C_Encrypt RC2 any input length rounded up to multiple of 8

C_Decrypt RC2 multiple of 8 between 1 and 8 bytes shorter than input length

C_WrapKey RC2 any input length rounded up to multiple of 8

C_UnwrapKey RC2 multiple of 8 between 1 and 8 bytes shorter than input length

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 effective number of bits.

General-length RC2-MAC

General-length RC2-MAC, denoted CKM_RC2_MAC_GENERAL, is a mechanism for single- and multiple-part signatures and verification, based on RSA Data Security's proprietary block cipher RC2 and data authentication as defined in FIPS PUB 113.

It has a parameter, a CK_RC2_MAC_GENERAL_PARAMS structure, which specifies the effective number of bits in the RC2 search space and the output length desired from the mechanism.

The output bytes from this mechanism are taken from the start of the final RC2 cipher block produced in the MACing process.

Constraints on key types and the length of data are summarized in the following table:

Table 10-14, General-length RC2-MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign RC2 any 0-8, as specified in parameters

C_Verify RC2 any 0-8, as specified in parameters

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 effective number of bits.

RC2-MAC

RC2-MAC, denoted by CKM_RC2_MAC, is a special case of the general-length RC2-MAC mechanism (see Section). Instead of taking a CK_RC2_MAC_GENERAL_PARAMS parameter, it takes a CK_RC2_PARAMS parameter, which only contains the effective number of bits in the RC2 search space. RC2-MAC always produces and verifies 4-byte MACs.

Constraints on key types and the length of data are summarized in the following table:

Table 10-15, RC2-MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign RC2 any 4

C_Verify RC2 any 4

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC2 effective number of bits.

RC4 mechanisms

RC4 key generation

The RC4 key generation mechanism, denoted CKM_RC4_KEY_GEN, is a key generation mechanism for RSA Data Security's proprietary stream cipher RC4.

It does not have a parameter.

The mechanism generates RC4 keys with a particular length in bytes, as specified in the CKA_VALUE_LEN attribute of the template for the key.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key. Other attributes supported by the RC4 key type (specifically, the flags indicating which functions the key supports) may be specified in the template for the key, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC4 key sizes, in bits.

RC4

RC4, denoted CKM_RC4, is a mechanism for single- and multiple-part encryption and decryption based on RSA Data Security's proprietary stream cipher RC4.

It does not have a parameter.

Constraints on key types and the length of input and output data are summarized in the following table:

Table 10-16, RC4 Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt RC4 any same as input length no final part

C_Decrypt RC4 any same as input length no final part

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC4 key sizes, in bits.

The RC5 cipher

RC5 is a parametrizable block cipher for which RSA Data Security has applied for a patent. It has a variable wordsize, a variable keysize, and a variable number of rounds. The blocksize of RC5 is always equal to twice its wordsize.

RC5 mechanism parameters

CK_RC5_PARAMS

CK_RC5_PARAMS provides the parameters to the CKM_RC5_ECB and CKM_RC5_MAC mechanisms. It is defined as follows:

typdef struct CK_RC5_PARAMS {
CK_ULONG ulWordsize;
CK_ULONG ulRounds;
} CK_RC5_PARAMS;

ulWordsize wordsize of RC5 cipher in bytes

ulRounds number of rounds of RC5 encipherment
CK_RC5_PARAMS_PTR

CK_RC5_PARAMS_PTR points to a CK_RC5_PARAMS structure. It is implementation-dependent.

CK_RC5_CBC_PARAMS

CK_RC5_CBC_PARAMS is a structure that provides the parameters to the CKM_RC5_CBC and CKM_RC5_CBC_PAD mechanisms. It is defined as follows:

typedef struct CK_RC5_CBC_PARAMS {
CK_ULONG ulWordsize;
CK_ULONG ulRounds;
CK_BYTE_PTR pIv;
CK_ULONG ulIvLen;
} CK_RC5_CBC_PARAMS;

ulWordsize wordsize of RC5 cipher in bytes

ulRounds number of rounds of RC5 encipherment

pIv pointer to initialization vector (IV) for CBC encryption

ulIvLen length of initialization vector (must be same as blocksize)
CK_RC5_CBC_PARAMS_PTR

CK_RC5_CBC_PARAMS_PTR points to a CK_RC5_CBC_PARAMS structure. It is implementation-dependent.

CK_RC5_MAC_GENERAL_PARAMS

CK_RC5_MAC_GENERAL_PARAMS is a structure that provides the parameters to the CKM_RC5_MAC_GENERAL mechanism. It is defined as follows:

typedef struct CK_RC5_MAC_GENERAL_PARAMS {
CK_ULONG ulWordsize;
CK_ULONG ulRounds;
CK_ULONG ulMacLength;
} CK_RC5_MAC_GENERAL_PARAMS;

ulWordsize wordsize of RC5 cipher in bytes

ulRounds number of rounds of RC5 encipherment

ulMacLength length of the MAC produced, in bytes
CK_RC5_MAC_GENERAL_PARAMS_PTR

CK_RC5_MAC_GENERAL_PARAMS_PTR points to a CK_RC5_MAC_GENERAL_PARAMS structure. It is implementation-dependent.

RC5 mechanisms

RC5 key generation

The RC5 key generation mechanism, denoted CKM_RC5_KEY_GEN, is a key generation mechanism for RSA Data Security's block cipher RC5.

It does not have a parameter.

The mechanism generates RC5 keys with a particular length in bytes, as specified in the CKA_VALUE_LEN attribute of the template for the key.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key. Other attributes supported by the RC5 key type (specifically, the flags indicating which functions the key supports) may be specified in the template for the key, or else are assigned default initial values.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of RC5 key sizes, in bytes.

RC5-ECB

RC5-ECB, denoted CKM_RC5_ECB, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's block cipher RC5 and electronic codebook mode as defined in FIPS PUB 81.

It has a parameter, a CK_RC5_PARAMS, which indicates the wordsize and number of rounds of encryption to use.

This mechanism can wrap and unwrap any secret key. Of course, a particular token may not be able to wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with null bytes so that the resulting length is a multiple of the cipher blocksize (twice the wordsize). The output data is the same length as the padded input data. It does not wrap the key type, key length, or any other information about the key; the application must convey these separately.

For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the CKA_KEY_TYPE attributes of the template and, if it has one, and the key type supports it, the CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key type must be specified in the template.

Constraints on key types and the length of data are summarized in the following table:

Table 10-17, RC5-ECB: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt RC5 multiple of blocksize same as input length no final part

C_Decrypt RC5 multiple of blocksize same as input length no final part

C_WrapKey RC5 any input length rounded up to multiple of blocksize

C_UnwrapKey RC5 multiple of blocksize determined by type of key being unwrapped or CKA_VALUE_LEN

RC5-CBC

RC5-CBC, denoted CKM_RC5_CBC, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's block cipher RC5 and cipher-block chaining mode as defined in FIPS PUB 81.

It has a parameter, a CK_RC5_CBC_PARAMS structure, which specifies the wordsize and number of rounds of encryption to use, as well as the initialization vector for cipher block chaining mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-18, RC5-CBC: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt RC5 multiple of blocksize same as input length no final part

C_Decrypt RC5 multiple of blocksize same as input length no final part

C_WrapKey RC5 any input length rounded up to multiple of blocksize

C_UnwrapKey RC5 multiple of blocksize determined by type of key being unwrapped or CKA_VALUE_LEN

RC5-CBC with PKCS padding

RC5-CBC with PKCS padding, denoted CKM_RC5_CBC_PAD, is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping, based on RSA Data Security's block cipher RC5; cipher-block chaining mode as defined in FIPS PUB 81; and the block cipher padding method detailed in PKCS #7.

It has a parameter, a CK_RC5_CBC_PARAMS structure, which specifies the wordsize and number of rounds of encryption to use, as well as the initialization vector for cipher block chaining mode.

In addition to being able to wrap and unwrap secret keys, this mechanism can wrap and unwrap RSA, Diffie-Hellman, and DSA private keys (see Section for details). The entries in Table 10 -19 for data length constraints when wrapping and unwrapping keys do not apply to wrapping and unwrapping private keys.

Constraints on key types and the length of data are summarized in the following table:

Table 10-19, RC5-CBC with PKCS padding: Key And Data Length Constraints
Function Key type Input length Output length

C_Encrypt RC5 any input length rounded up to multiple of blocksize

C_Decrypt RC5 multiple of blocksize between 1 and blocksize bytes shorter than input length

C_WrapKey RC5 any input length rounded up to multiple of blocksize

C_UnwrapKey RC5 multiple of blocksize between 1 and blocksize bytes shorter than input length

General-length RC5-MAC

General-length RC5-MAC, denoted CKM_RC5_MAC_GENERAL, is a mechanism for single- and multiple-part signatures and verification, based on RSA Data Security's block cipher RC5 and data authentication as defined in FIPS PUB 113.

It has a parameter, a CK_RC5_MAC_GENERAL_PARAMS structure, which specifies the wordsize and number of rounds of encryption to use and the output length desired from the mechanism.

The output bytes from this mechanism are taken from the start of the final RC5 cipher block produced in the MACing process.

Constraints on key types and the length of data are summarized in the following table:

Table 10-20, General-length RC2-MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign RC2 any 0-blocksize, as specified in parameters

C_Verify RC2 any 0-blocksize, as specified in parameters

RC5-MAC

RC5-MAC, denoted by CKM_RC5_MAC, is a special case of the general-length RC5-MAC mechanism (see Section). Instead of taking a CK_RC5_MAC_GENERAL_PARAMS parameter, it takes a CK_RC5_PARAMS parameter. RC5-MAC always produces and verifies MACs half as large as the RC5 blocksize.

Constraints on key types and the length of data are summarized in the following table:

Table 10-21, RC5-MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign RC5 any RC5 wordsize = LOWER(blocksize/2)

C_Verify RC5 any RC5 wordsize = LOWER(blocksize/2)

General block cipher mechanism parameters

CK_MAC_GENERAL_PARAMS

CK_MAC_GENERAL_PARAMS provides the parameters to the general-length MACing mechanisms of the DES, DES3 (triple-DES), CAST, CAST3, CAST5, IDEA, and CDMF ciphers. It holds the length of the MAC that these mechanisms will produce. It is defined as follows:

typedef CK_ULONG CK_MAC_GENERAL_PARAMS;

CK_MAC_GENERAL_PARAMS_PTR

CK_MAC_GENERAL_PARAMS_PTR points to a CK_MAC_GENERAL_PARAMS. It is implementation-dependent.

General block cipher mechanisms

For brevity's sake, the mechanisms for the DES, DES3 (triple-DES), CAST, CAST3, CAST5, IDEA, and CDMF block ciphers will be described together here. Each of these ciphers has the following mechanisms, which will be described in a templatized form:

General block cipher key generation

Cipher <NAME> has a key generation mechanism, "<NAME> key generation", denoted CKM_<NAME>_KEY_GEN.

This mechanism does not have a parameter.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key. Other attributes supported by the key type (specifically, the flags indicating which functions the key supports) may be specified in the template for the key, or else are assigned default initial values.

When DES keys or CDMF keys are generated, their parity bits are set properly, as specified in FIPS PUB 46-2. Similarly, when a triple-DES key is generated, each of the DES keys comprising it has its parity bits set properly.

When DES or CDMF keys are generated, it is token-dependent whether or not it is possible for "weak" or "semi-weak" keys to be generated. Similarly, when triple-DES keys are generated, it is token dependent whether or not it is possible for any of the component DES keys to be "weak" or "semi-weak" keys.

When CAST, CAST3, or CAST5 keys are generated, the template for the secret key must specify a CKA_VALUE_LEN attribute.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure may or may not be used. The CAST, CAST3, and CAST5 ciphers have variable key sizes, and so for the the key generation mechanisms for these ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA, and CDMF ciphers, these fields are not used.

General block cipher ECB

Cipher <NAME> has an electronic codebook mechanism, "<NAME>-ECB", denoted CKM_<NAME>_ECB. It is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping with <NAME>.

It does not have a parameter.

This mechanism can wrap and unwrap any secret key. Of course, a particular token may not be able to wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with null bytes so that the resulting length is a multiple of <NAME>'s blocksize. The output data is the same length as the padded input data. It does not wrap the key type, key length or any other information about the key; the application must convey these separately.

Constraints on key types and the length of data are summarized in the following table:

Table 10-22, General block cipher ECB: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt <NAME> multiple of blocksize same as input length no final part

C_Decrypt <NAME> multiple of blocksize same as input length no final part

C_WrapKey <NAME> any input length rounded up to multiple of blocksize

C_UnwrapKey <NAME> any determined by type of key being unwrapped or CKA_VALUE_LEN

General block cipher CBC

Cipher <NAME> has a cipher-block chaining mode, "<NAME>-CBC", denoted CKM_<NAME>_CBC. It is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping with <NAME>.

It has a parameter, an initialization vector for cipher block chaining mode. The initialization vector has the same length as <NAME>'s blocksize.

Constraints on key types and the length of data are summarized in the following table:

Table 10-23, General block cipher CBC: Key And Data Length Constraints
Function Key type Input length Output length Comments

C_Encrypt <NAME> multiple of blocksize same as input length no final part

C_Decrypt <NAME> multiple of blocksize same as input length no final part

C_WrapKey <NAME> any input length rounded up to multiple of blocksize

C_UnwrapKey <NAME> any determined by type of key being unwrapped or CKA_VALUE_LEN

General block cipher CBC with PKCS padding

Cipher <NAME> has a cipher-block chaining mode with PKCS padding, "<NAME>-CBC with PKCS padding", denoted CKM_<NAME>_CBC_PAD. It is a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping with <NAME>. All ciphertext is padded with PKCS padding.

It has a parameter, an initialization vector for cipher block chaining mode. The initialization vector has the same length as <NAME>'s blocksize.

In addition to being able to wrap and unwrap secret keys, this mechanism can wrap and unwrap RSA, Diffie-Hellman, and DSA private keys (see Section for details). The entries in Table 10 -24 for data length constraints when wrapping and unwrapping keys do not apply to wrapping and unwrapping private keys.

Constraints on key types and the length of data are summarized in the following table:

Table 10-24, General block cipher CBC with PKCS padding: Key And Data Length Constraints
Function Key type Input length Output length

C_Encrypt <NAME> any input length rounded up to multiple of blocksize

C_Decrypt <NAME> multiple of blocksize between 1 and blocksize bytes shorter than input length

C_WrapKey <NAME> any input length rounded up to multiple of blocksize

C_UnwrapKey <NAME> multiple of blocksize between 1 and blocksize bytes shorter than input length

General-length general block cipher MAC

Cipher <NAME> has a general-length MACing mode, "General-length <NAME>-MAC", denoted CKM_<NAME>_MAC_GENERAL. It is a mechanism for single- and multiple-part signatures and verification.

It has a parameter, a CK_MAC_GENERAL_PARAMS, which specifies the size of the output.

The output bytes from this mechanism are taken from the start of the final cipher block produced in the MACing process.

Constraints on key types and the length of input and output data are summarized in the following table:

Table 10-25, General-length general block cipher MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign <NAME> any 0-blocksize, depending on parameters

C_Verify <NAME> any 0-blocksize, depending on parameters

General block cipher MAC

Cipher <NAME> has a MACing mechanism, "<NAME>-MAC", denoted CKM_<NAME>_MAC. This mechanism is a special case of the CKM_<NAME>_MAC_GENERAL mechanism described in SECTION_ "Section ." It always produces an output of size half as large as <NAME>'s blocksize.

This mechanism has no parameters.

Constraints on key types and the length of data are summarized in the following table:

Table 10-26, General block cipher MAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign <NAME> any LOWER(blocksize/2)

C_Verify <NAME> any LOWER(blocksize/2)

Double-length DES mechanisms

Double-length DES key generation

The double-length DES key generation mechanism, denoted CKM_DES2_KEY_GEN, is a key generation mechanism for double-length DES keys. The DES keys making up a double-length DES key both have their parity bits set properly, as specified in FIPS PUB 46-2.

It does not have a parameter.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key. Other attributes supported by the double-length DES key type (specifically, the flags indicating which functions the key supports) may be specified in the template for the key, or else are assigned default initial values.

Double-length DES keys can be used with all the same mechanisms as triple-DES keys: CKM_DES_ECB, CKM_DES_CBC, CKM_DES_CBC_PAD, CKM_DES_MAC_GENERAL, and CKM_DES_MAC (these mechanisms are described in templatized form in Section). Triple-DES encryption with a double-length DES key consists of three steps: encryption with the first DES key; decryption with the second DES key; and encryption with the first DES key.

When double-length DES keys are generated, it is token-dependent whether or not it is possible for either of the component DES keys to be "weak" or "semi-weak" keys.

SKIPJACK mechanism parameters

CK_SKIPJACK_PRIVATE_WRAP_PARAMS

CK_SKIPJACK_PRIVATE_WRAP_PARAMS is a structure that provides the parameters to the CKM_SKIPJACK_PRIVATE_WRAP mechanism. It is defined as follows:

typedef struct CK_SKIPJACK_PRIVATE_WRAP_PARAMS {
CK_ULONG ulPasswordLen;
CK_BYTE_PTR pPassword;
CK_ULONG ulPublicDataLen;
CK_BYTE_PTR pPublicData;
CK_ULONG ulPandGLen;
CK_ULONG ulQLen;
CK_ULONG ulRandomLen;
CK_BYTE_PTR pRandomA;
CK_BYTE_PTR pPrimeP;
CK_BYTE_PTR pBaseG;
CK_BYTE_PTR pSubprimeQ;
} CK_SKIPJACK_PRIVATE_WRAP_PARAMS;

ulPasswordLen length of the password

pPassword pointer to the buffer which contains the user-supplied password

ulPublicDataLen other party's key exchange public key size

pPublicData pointer to other party's key exchange public key value

ulPandGLen length of prime and base values

ulQLen length of subprime value

ulRandomLen size of random Ra, in bytes

pRandomA pointer to Ra data

pPrimeP pointer to Prime, p, value

pBaseG pointer to Base, g, value

pSubprimeQ pointer to Subprime, q, value
CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR

CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR points to a CK_PRIVATE_WRAP_PARAMS structure. It is implementation-dependent.

CK_SKIPJACK_RELAYX_PARAMS

CK_SKIPJACK_RELAYX_PARAMS is a structure that provides the parameters to the CKM_SKIPJACK_RELAYX mechanism. It is defined as follows:

typedef struct CK_SKIPJACK_RELAYX_PARAMS {
CK_ULONG ulOldWrappedXLen;
CK_BYTE_PTR pOldWrappedX;
CK_ULONG ulOldPasswordLen;
CK_BYTE_PTR pOldPassword;
CK_ULONG ulOldPublicDataLen;
CK_BYTE_PTR pOldPublicData;
CK_ULONG ulOldRandomLen;
CK_BYTE_PTR pOldRandomA;
CK_ULONG ulNewPasswordLen;
CK_BYTE_PTR pNewPassword;
CK_ULONG ulNewPublicDataLen;
CK_BYTE_PTR pNewPublicData;
CK_ULONG ulNewRandomLen;
CK_BYTE_PTR pNewRandomA;
} CK_SKIPJACK_RELAYX_PARAMS;

ulOldWrappedXLen length of old wrapped key in bytes

pOldWrappedX pointer to old wrapper key

ulOldPasswordLen length of the old password

pOldPassword pointer to the buffer which contains the old user-supplied password

ulOldPublicDataLen old key exchange public key size

pOldPublicData pointer to old key exchange public key value

ulOldRandomLen size of old random Ra in bytes

pOldRandomA pointer to old Ra data

ulNewPasswordLen length of the new password

pNewPassword pointer to the buffer which contains the new user-supplied password

ulNewPublicDataLen new key exchange public key size

pNewPublicData pointer to new key exchange public key value

ulNewRandomLen size of new random Ra in bytes

pNewRandomA pointer to new Ra data
CK_SKIPJACK_RELAYX_PARAMS_PTR

CK_SKIPJACK_RELAYX_PARAMS_PTR points to a CK_SKIPJACK_RELAYX_PARAMS structure. It is implementation-dependent.

SKIPJACK mechanisms

SKIPJACK key generation

The SKIPJACK key generation mechanism, denoted CKM_SKIPJACK_KEY_GEN, is a key generation mechanism for SKIPJACK. The output of this mechanism is called a Message Encryption Key (MEK).

It does not have a parameter.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key.

SKIPJACK-ECB64

SKIPJACK-ECB64, denoted CKM_SKIPJACK_ECB64, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 64-bit electronic codebook mode as defined in FIPS PUB 185.

It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some value generated by the token"in other words, the application cannot specify a particular IV when encrypting. It can, of course, specify a particular IV when decrypting.

Constraints on key types and the length of data are summarized in the following table:

Table 10-27, SKIPJACK-ECB64: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 8 same as input length no final part

C_Decrypt SKIPJACK multiple of 8 same as input length no final part

SKIPJACK-CBC64

SKIPJACK-CBC64, denoted CKM_SKIPJACK_CBC64, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 64-bit cipher-block chaining mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-28, SKIPJACK-CBC64: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 8 same as input length no final part

C_Decrypt SKIPJACK multiple of 8 same as input length no final part

SKIPJACK-OFB64

SKIPJACK-OFB64, denoted CKM_SKIPJACK_OFB64, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 64-bit output feedback mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-29, SKIPJACK-OFB64: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 8 same as input length no final part

C_Decrypt SKIPJACK multiple of 8 same as input length no final part

SKIPJACK-CFB64

SKIPJACK-CFB64, denoted CKM_SKIPJACK_CFB64, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 64-bit cipher feedback mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-30, SKIPJACK-CFB64: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 8 same as input length no final part

C_Decrypt SKIPJACK multiple of 8 same as input length no final part

SKIPJACK-CFB32

SKIPJACK-CFB32, denoted CKM_SKIPJACK_CFB32, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 32-bit cipher feedback mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-31, SKIPJACK-CFB32: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 4 same as input length no final part

C_Decrypt SKIPJACK multiple of 4 same as input length no final part

SKIPJACK-CFB16

SKIPJACK-CFB16, denoted CKM_SKIPJACK_CFB16, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 16-bit cipher feedback mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-32, SKIPJACK-CFB16: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 4 same as input length no final part

C_Decrypt SKIPJACK multiple of 4 same as input length no final part

SKIPJACK-CFB8

SKIPJACK-CFB8, denoted CKM_SKIPJACK_CFB8, is a mechanism for single- and multiple-part encryption and decryption with SKIPJACK in 8-bit cipher feedback mode as defined in FIPS PUB 185.

Constraints on key types and the length of data are summarized in the following table:

Table 10-33, SKIPJACK-CFB8: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt SKIPJACK multiple of 4 same as input length no final part

C_Decrypt SKIPJACK multiple of 4 same as input length no final part

SKIPJACK-WRAP

The SKIPJACK-WRAP mechanism, denoted CKM_SKIPJACK_WRAP, is used to wrap and unwrap a secret key (MEK). It can wrap or unwrap SKIPJACK, BATON, and JUNIPER keys.

It does not have a parameter.

SKIPJACK-PRIVATE-WRAP

The SKIPJACK-PRIVATE-WRAP mechanism, denoted CKM_SKIPJACK_PRIVATE_WRAP, is used to wrap and unwrap a private key. It can wrap KEA and DSA private keys.

It has a parameter, a CK_SKIPJACK_PRIVATE_WRAP_PARAMS structure

SKIPJACK-RELAYX

The SKIPJACK-RELAYX mechanism, denoted CKM_SKIPJACK_RELAYX, is used with the C_WrapKey function to "change the wrapping" on a private key which was wrapped with the SKIPJACK-PRIVATE-WRAP mechanism (see Section).

It has a parameter, a CK_SKIPJACK_RELAYX_PARAMS structure.

Although the SKIPJACK-RELAYX mechanism is used with C_WrapKey, it differs from other key-wrapping mechanisms. Other key-wrapping mechanisms take a key handle as one of the arguments to C_WrapKey ; however, for the SKIPJACK_RELAYX mechanism, the [always invalid] value 0 should be passed as the key handle for C_WrapKey, and the already-wrapped key is passed in as part of the CK_SKIPJACK_RELAYX_PARAMS structure.

BATON mechanisms

BATON key generation

The BATON key generation mechanism, denoted CKM_BATON_KEY_GEN, is a key generation mechanism for BATON. The output of this mechanism is called a Message Encryption Key (MEK).

It does not have a parameter.

This mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key.

BATON-ECB128

BATON-ECB128, denoted CKM_BATON_ECB128, is a mechanism for single- and multiple-part encryption and decryption with BATON in 128-bit electronic codebook mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-34, BATON-ECB128: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt BATON multiple of 16 same as input length no final part

C_Decrypt BATON multiple of 16 same as input length no final part

BATON-ECB96

BATON-ECB96, denoted CKM_BATON_ECB96, is a mechanism for single- and multiple-part encryption and decryption with BATON in 96-bit electronic codebook mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-35, BATON-ECB96: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt BATON multiple of 12 same as input length no final part

C_Decrypt BATON multiple of 12 same as input length no final part

BATON-CBC128

BATON-CBC128, denoted CKM_BATON_CBC128, is a mechanism for single- and multiple-part encryption and decryption with BATON in 128-bit cipher-block chaining mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-36, BATON-CBC128: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt BATON multiple of 16 same as input length no final part

C_Decrypt BATON multiple of 16 same as input length no final part

BATON-COUNTER

BATON-COUNTER, denoted CKM_BATON_COUNTER, is a mechanism for single- and multiple-part encryption and decryption with BATON in counter mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-37, BATON-COUNTER: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt BATON multiple of 16 same as input length no final part

C_Decrypt BATON multiple of 16 same as input length no final part

BATON-SHUFFLE

BATON-SHUFFLE, denoted CKM_BATON_SHUFFLE, is a mechanism for single- and multiple-part encryption and decryption with BATON in shuffle mode.

Constraints on key types and the length of data are summarized in the following table:

Table 10-38, BATON-SHUFFLE: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt BATON multiple of 16 same as input length no final part

C_Decrypt BATON multiple of 16 same as input length no final part

BATON WRAP

The BATON wrap and unwrap mechanism, denoted CKM_BATON_WRAP, is a function used to wrap and unwrap a secret key (MEK). It can wrap and unwrap SKIPJACK, BATON, and JUNIPER keys.

It has no parameters.

When used to unwrap a key, this mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to it.

JUNIPER mechanisms

JUNIPER key generation

The JUNIPER key generation mechanism, denoted CKM_JUNIPER_KEY_GEN, is a key generation mechanism for JUNIPER. The output of this mechanism is called a Message Encryption Key (MEK).

It does not have a parameter.

The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key.

JUNIPER-ECB128

JUNIPER-ECB128, denoted CKM_JUNIPER_ECB128, is a mechanism for single- and multiple-part encryption and decryption with JUNIPER in 128-bit electronic codebook mode.

Constraints on key types and the length of data are summarized in the following table. For encryption and decryption, the input and output data (parts) may begin at the same location in memory.

Table 10-39, JUNIPER-ECB128: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt JUNIPER multiple of 16 same as input length no final part

C_Decrypt JUNIPER multiple of 16 same as input length no final part

JUNIPER-CBC128

JUNIPER-CBC128, denoted CKM_JUNIPER_CBC128, is a mechanism for single- and multiple-part encryption and decryption with JUNIPER in 128-bit cipher-block chaining mode.

Constraints on key types and the length of data are summarized in the following table. For encryption and decryption, the input and output data (parts) may begin at the same location in memory.

Table 10-40, JUNIPER-CBC128: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt JUNIPER multiple of 16 same as input length no final part

C_Decrypt JUNIPER multiple of 16 same as input length no final part

JUNIPER-COUNTER

JUNIPER COUNTER, denoted CKM_JUNIPER_COUNTER, is a mechanism for single- and multiple-part encryption and decryption with JUNIPER in counter mode.

Constraints on key types and the length of data are summarized in the following table. For encryption and decryption, the input and output data (parts) may begin at the same location in memory.

Table 10-41, JUNIPER-COUNTER: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt JUNIPER multiple of 16 same as input length no final part

C_Decrypt JUNIPER multiple of 16 same as input length no final part

JUNIPER-SHUFFLE

JUNIPER-SHUFFLE, denoted CKM_JUNIPER_SHUFFLE, is a mechanism for single- and multiple-part encryption and decryption with JUNIPER in shuffle mode.

Constraints on key types and the length of data are summarized in the following table. For encryption and decryption, the input and output data (parts) may begin at the same location in memory.

Table 10-42, JUNIPER-SHUFFLE: Data and Length Constraints
Function Key type Input length Output length Comments

C_Encrypt JUNIPER multiple of 16 same as input length no final part

C_Decrypt JUNIPER multiple of 16 same as input length no final part

JUNIPER WRAP

The JUNIPER wrap and unwrap mechanism, denoted CKM_JUNIPER_WRAP, is a function used to wrap and unwrap an MEK. It can wrap or unwrap SKIPJACK, BATON, and JUNIPER keys.

It has no parameters.

When used to unwrap a key, this mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to it.

MD2 mechanisms

MD2

The MD2 mechanism, denoted CKM_MD2, is a mechanism for message digesting, following the MD2 message-digest algorithm defined in RFC 1319.

It does not have a parameter.

Constraints on the length of data are summarized in the following table:

Table 10-43, MD2: Data Length Constraints
Function Data length Digest length

C_Digest any 16

General-length MD2-HMAC

The general-length MD2-HMAC mechanism, denoted CKM_MD2_HMAC_GENERAL, is a mechanism for signatures and verification. It uses the HMAC construction, based on the MD2 hash function. The keys it uses are generic secret keys.

It has a parameter, a CKA_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired output. This length should be in the range 0-16 (the output size of MD2 is 16 bytes). Signatures produced by this mechanism will be taken from the start of the full 16-byte HMAC output.

Table 10-44, General-length MD2-HMAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign generic secret any 0-16, depending on parameters

C_Verify generic secret any 0-16, depending on parameters

MD2-HMAC

The MD2-HMAC mechanism, denoted CKM_MD2_HMAC, is a special case of the general-length MD2-HMAC mechanism in Section .

It has no parameter, and always produces an output of length 16.

MD2 key derivation

MD2 key derivation, denoted CKM_MD2_KEY_DERIVATION, is a mechanism which provides the capability of deriving a secret key by digesting the value of another secret key with MD2.

The value of the base key is digested once, and the result is used to make the value of derived secret key.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be 16 bytes (the output size of MD2).
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length was provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more than 16 bytes, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key can both be specified to be either TRUE or FALSE. If omitted, these attributes each take on some default value.
If the base key has its CKA_ALWAYS_SENSITIVE attribute set to FALSE, then the derived key will as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its CKA_SENSITIVE attribute.
Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to FALSE, then the derived key will, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute. MD5 mechanisms

MD5

The MD5 mechanism, denoted CKM_MD5, is a mechanism for message digesting, following the MD5 message-digest algorithm defined in RFC 1321.

It does not have a parameter.

Constraints on the length of input and output data are summarized in the following table. For single-part digesting, the data and the digest may begin at the same location in memory.

Table 10-45, MD5: Data Length Constraints
Function Data length Digest length

C_Digest any 16

General-length MD5-HMAC

The general-length MD5-HMAC mechanism, denoted CKM_MD5_HMAC_GENERAL, is a mechanism for signatures and verification. It uses the HMAC construction, based on the MD5 hash function. The keys it uses are generic secret keys.

It has a parameter, a CKA_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired output. This length should be in the range 0-16 (the output size of MD5 is 16 bytes). Signatures produced by this mechanism will be taken from the start of the full 16-byte HMAC output.

Table 10-46, General-length MD5-HMAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign generic secret any 0-16, depending on parameters

C_Verify generic secret any 0-16, depending on parameters

MD5-HMAC

The MD5-HMAC mechanism, denoted CKM_MD5_HMAC, is a special case of the general-length MD5-HMAC mechanism in Section .

It has no parameter, and always produces an output of length 16.

MD5 key derivation

MD5 key derivation, denoted CKM_MD5_KEY_DERIVATION, is a mechanism which provides the capability of deriving a secret key by digesting the value of another secret key with MD5.

The value of the base key is digested once, and the result is used to make the value of derived secret key.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be 16 bytes (the output size of MD5).
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length was provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more than 16 bytes, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key can both be specified to be either TRUE or FALSE. If omitted, these attributes each take on some default value.
If the base key has its CKA_ALWAYS_SENSITIVE attribute set to FALSE, then the derived key will as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its CKA_SENSITIVE attribute.
Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to FALSE, then the derived key will, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute. SHA-1 mechanisms

SHA-1

The SHA-1 mechanism, denoted CKM_SHA_1, is a mechanism for message digesting, following the Secure Hash Algorithm defined in FIPS PUB 180, as subsequently amended by NIST.

It does not have a parameter.

Constraints on the length of input and output data are summarized in the following table. For single-part digesting, the data and the digest may begin at the same location in memory.

Table 10-47, SHA-1: Data Length Constraints
Function Input length Digest length

C_Digest any 20

General-length SHA-1-HMAC

The general-length SHA-1-HMAC mechanism, denoted CKM_SHA_1_HMAC_GENERAL, is a mechanism for signatures and verification. It uses the HMAC construction, based on the SHA-1 hash function. The keys it uses are generic secret keys.

It has a parameter, a CKA_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired output. This length should be in the range 0-20 (the output size of SHA-1 is 20 bytes). Signatures produced by this mechanism will be taken from the start of the full 20-byte HMAC output.

Table 10-48, General-length SHA-1-HMAC: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign generic secret any 0-20, depending on parameters

C_Verify generic secret any 0-20, depending on parameters

SHA-1-HMAC

The SHA-1-HMAC mechanism, denoted CKM_SHA_1_HMAC, is a special case of the general-length SHA-1-HMAC mechanism in Section .

It has no parameter, and always produces an output of length 20.

SHA-1 key derivation

SHA-1 key derivation, denoted CKM_SHA1_KEY_DERIVATION, is a mechanism which provides the capability of deriving a secret key by digesting the value of another secret key with SHA-1.

The value of the base key is digested once, and the result is used to make the value of derived secret key.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be 20 bytes (the output size of SHA-1).
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length was provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more than 20 bytes, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key can both be specified to be either TRUE or FALSE. If omitted, these attributes each take on some default value.
If the base key has its CKA_ALWAYS_SENSITIVE attribute set to FALSE, then the derived key will as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its CKA_SENSITIVE attribute.
Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to FALSE, then the derived key will, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute. FASTHASH mechanisms

FASTHASH

The FASTHASH mechanism, denoted CKM_FASTHASH, is a mechanism for message digesting, following the U. S. government's algorithm.

It does not have a parameter.

Constraints on the length of input and output data are summarized in the following table:

Table 10-49, FASTHASH: Data Length Constraints
Function Input length Digest length

C_Digest any 40

Password-based encryption mechanism parameters

CK_PBE_PARAMS

CK_PBE_PARAMS is a structure which provides all of the necessary information required by the CKM_PBE mechanisms (see PKCS#5 for information on the PBE generation mechanisms). It is defined as follows:

typedef struct CK_PBE_PARAMS {
CK_CHAR_PTR pInitVector;
CK_CHAR_PTR pPassword;
CK_ULONG ulPasswordLen;
CK_CHAR_PTR pSalt;
CK_ULONG ulSaltLen;
CK_ULONG ulIteration;
} CK_PBE_PARAMS;

pInitVector pointer to the location that receives the 8-byte initialization vector (IV);

pPassword points to the password to be used in the PBE key generation;

ulPasswordLen length in bytes of the password information;

pSalt points to the salt to be used in the PBE key generation;

usSaltLen length in bytes of the salt information;

usIteration number of iterations required for the generation.
CK_PBE_PARAMS_PTR

CK_PBE_PARAMS_PTR points to a CK_PBE_PARAMS structure. It is implementation-dependent.

Password-based encryption mechanisms

MD2-PBE for DES-CBC

MD2-PBE for DES-CBC, denoted CKM_PBE_MD2_DES_CBC, is a mechanism used for generating a DES secret key and an initialization vector by using a password and a salt value and the MD2 digest algorithm. This functionality is defined in PKCS#5.

It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the key generation process and the location of the application-supplied buffer which will receive the 8-byte IV generated by the mechanism.

MD5-PBE for DES-CBC

MD5-PBE for DES-CBC, denoted CKM_PBE_MD5_DES_CBC, is a mechanism used for generating a DES secret key and an initialization vector by using a password and a salt value and the MD5 digest algorithm. This functionality is defined in PKCS#5.

MD5-PBE for CAST-CBC

MD5-PBE for CAST-CBC, denoted CKM_PBE_MD5_CAST_CBC, is a mechanism used for generating a CAST secret key and an initialization vector by using a password and a salt value and the MD5 digest algorithm. This functionality is essentially that defined in PKCS#5.

The CAST key generated by this mechanism is 8 bytes long.

MD5-PBE for CAST3-CBC

MD5-PBE for CAST3-CBC, denoted CKM_PBE_MD5_CAST3_CBC, is a mechanism used for generating a CAST3 secret key and an initialization vector by using a password and a salt value and the MD5 digest algorithm. This functionality is essentially that defined in PKCS#5.

The CAST3 key generated by this mechanism is 8 bytes long.

MD5-PBE for CAST5-CBC

MD5-PBE for CAST5-CBC, denoted CKM_PBE_MD5_CAST5_CBC, is a mechanism used for generating a CAST5 secret key and an initialization vector by using a password and a salt value and the MD5 digest algorithm. This functionality is essentially that defined in PKCS#5.

The CAST5 key generated by this mechanism is 8 bytes long.

SET mechanism parameters

CK_KEY_WRAP_SET_OAEP_PARAMS

CK_KEY_WRAP_SET_OAEP_PARAMS is a structure that provides the parameters to the CKM_KEY_WRAP_SET_OAEP mechanism. It is defined as follows:

typedef struct CK_KEY_WRAP_SET_OAEP_PARAMS {
CK_BYTE bBC;
CK_BYTE_PTR pX;
CK_ULONG ulXLen;
} CK_KEY_WRAP_SET_OAEP_PARAMS;

bBC block contents byte

pX extra data

ulXLen length in bytes of extra data
CK_KEY_WRAP_SET_OAEP_PARAMS_PTR

CK_KEY_WRAP_SET_OAEP_PARAMS_PTR points to a CK_KEY_WRAP_SET_OAEP_PARAMS structure. It is implementation-dependent.

SET mechanisms

OAEP key wrapping for SET

The OAEP key wrapping for SET mechanism, denoted CKM_KEY_WRAP_SET_OAEP, is a mechanism for wrapping and unwrapping DES keys (and possibly some extra data) with RSA keys. This mechanism is defined in the SET protocol specifications.

It takes a parameter, a CK_KEY_WRAP_SET_OAEP_PARAMS structure. This structure holds the "Block Contents" byte of the data, as well as any extra data. If no extra data is present, that is indicated by the ulXLen field having the value 0.

When this mechanism is used to unwrap a key, the extra data is returned following the convention described in Section on producing output. If the inputs to C_UnwrapKey are such that the extra data is not returned (e.g., the buffer supplied in the CK_KEY_WRAP_SET_OAEP_PARAMS structure is NULL_PTR), then the unwrapped key object will not be created, either.

Note that when this mechanism is used to unwrap a key, the bBC and pX fields of the parameter supplied to the mechanism may be modified.

If an application uses C_UnwrapKey with CKM_KEY_WRAP_SET_OAEP, it is general preferable to simply allocate a 128-byte buffer for the extra data (the extra data is never larger than 128 bytes), rather than calling C_UnwrapKey twice. Each call of C_UnwrapKey with CKM_KEY_WRAP_SET_OAEP requires an RSA decryption operation to be performed, and this overhead can be avoided by this means.

LYNKS mechanisms

LYNKS key wrapping

The LYNKS key wrapping mechanism, denoted CKM_WRAP_LYNKS, is a mechanism for wrapping and unwrapping secret keys with DES keys. It can wrap any 8-byte secret key, and it produces a 10-byte wrapped key, containing a cryptographic checksum.

It does not have a parameter.

When unwrapping a key with this mechanism, if the cryptographic checksum does not check out properly, an error is returned. In addition, if a DES key or CDMF key is unwrapped with this mechanism, the parity bits on the wrapped key must be set appropriately; if they are not set properly, an error is returned.

SSL mechanism parameters

CK_SSL3_RANDOM_DATA

CK_SSL3_RANDOM_DATA is a structure which provides information about the random data of a client and a server in an SSL context. This structure is used by both the CKM_SSL3_MASTER_KEY_DERIVE and the CKM_SSL3_KEY_AND_MAC_DERIVE mechanisms. It is defined as follows:

typedef struct CK_SSL3_RANDOM_DATA {
CK_BYTE_PTR pClientRandom;
CK_ULONG ulClientRandomLen;
CK_BYTE_PTR pServerRandom;
CK_ULONG ulServerRandomLen;
} CK_SSL3_RANDOM_DATA;

pClientRandom pointer to the client's random data. (see SSL 3.0 for details)

ulClientRandomLen length in bytes of the client's random data

pServerRandom pointer to the server's random data. (see SSL 3.0 for details)

ulServerRandomLen length in bytes of the server's random data
CK_SSL3_MASTER_KEY_DERIVE_PARAMS

CK_SSL3_MASTER_KEY_DERIVE_PARAMS is a structure that provides the parameters to the CKM_SSL3_MASTER_KEY_DERIVE mechanism. It is defined as follows:

typedef struct CK_SSL3_MASTER_KEY_DERIVE_PARAMS {
CK_SSL3_RANDOM_DATA RandomInfo;
CK_VERSION_PTR pVersion;
} CK_SSL3_MASTER_KEY_DERIVE_PARAMS;

RandomInfo client's and server's random data information.

pVersion pointer to a '''CK_VERSION '''structure which receives the SSL protocol version information (see SSL 3.0 for details)
CK_SSL3_MASTER_KEY_DERIVE_PARAMS_PTR

CK_SSL3_MASTER_KEY_DERIVE_PARAMS_PTR points to a CK_SSL3_MASTER_KEY_DERIVE_PARAMS structure. It is implementation-dependent.

CK_SSL3_KEY_MAT_OUT

CK_SSL3_KEY_MAT_OUT is a structure that contains the resulting key handles after performing a C_DeriveKey function with the CKM_SSL3_KEY_AND_MAC_DERIVE mechanism. It is defined as follows:

typedef struct CK_SSL3_KEY_MAT_OUT {
CK_OBJECT_HANDLE hClientMacSecret;
CK_OBJECT_HANDLE hServerMacSecret;
CK_OBJECT_HANDLE hClientKey;
CK_OBJECT_HANDLE hServerKey;
CK_BYTE_PTR pIVClient;
CK_BYTE_PTR pIVServer;
} CK_SSL3_KEY_MAT_OUT;

hClientMacSecret key handle for the resulting Client MAC Secret key

hServerMacSecret key handle for the resulting Server MAC Secret key

hClientKey key handle for the resulting Client Secret key

hServerKey key handle for the resulting Server Secret key

pIVClient pointer to a location which receives the initialization vector (IV) created for the client, if any (see SSL 3.0 for details)

pIVServer pointer to a location which receives the initialization vector (IV) created for the server, if any (see SSL 3.0 for details)
CK_SSL3_KEY_MAT_OUT_PTR

CK_SSL3_KEY_MAT_OUT_PTR points to a CK_SSL3_KEY_MAT_OUT structure. It is implementation-dependent.

CK_SSL3_KEY_MAT_PARAMS

CK_SSL3_KEY_MAT_PARAMS is a structure that provides the parameters to the CKM_SSL3_KEY_AND_MAC_DERIVE mechanism. It is defined as follows:

typedef struct CK_SSL3_KEY_MAT_PARAMS {
CK_ULONG ulMacSizeInBits;
CK_ULONG ulKeySizeInBits;
CK_ULONG ulIVSizeInBits;
CK_BBOOL bIsExport;
CK_SSL3_RANDOM_DATA RandomInfo;
CK_SSL3_KEY_MAT_OUT_PTR pReturnedKeyMaterial;
} CK_SSL3_KEY_MAT_PARAMS;

ulMacSizeInBits establishes the length (in bits) of the MACing keys agreed upon during the protocol handshake phase (see SSL 3.0 for details)

ulKeySizeInBits establishes the length (in bits) of the secret keys agreed upon during the protocol handshake phase (see SSL 3.0 for details)

ulIVSizeInBits establishes the length (in bits) of the IV agreed upon during the protocol handshake phase. If no IV is required, the length should be set to 0 (see SSL 3.0 for details)

bIsExport a boolean value which indicates whether the keys have to be derived for an export version of the protocol (see SSL 3.0 for details)

RandomInfo client's and server's random data information.

pReturnedKeyMaterial points to a '''CK_SSL3_KEY_MAT_OUT''' structures which receives the handles for the keys generated, as well as the IVs when required (see SSL 3.0 for details)
CK_SSL3_KEY_MAT_PARAMS_PTR

CK_SSL3_KEY_MAT_PARAMS_PTR points to a CK_SSL3_KEY_MAT_PARAMS structure. It is implementation-dependent.

SSL mechanisms

Pre_master key generation

Pre_master key generation in SSL 3.0, denoted CKM_SSL3_PRE_MASTER_KEY_GEN, is a mechanism which generates a 48-byte generic secret key. It is used to produce the "pre_master" key used in SSL version 3.0.

It has one parameter, a CK_VERSION structure, which provides the client's SSL version number.

The mechanism contributes to the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new key (as well as the CKA_VALUE_LEN attribute, if it is not supplied in the template). Other attributes may be specified in the template, or else are assigned default values.

The template sent along with this mechanism during a C_GenerateKey call may indicate that the object class is CKO_SECRET_KEY, the key type is CKK_GENERIC_SECRET, and the CKA_VALUE_LEN attribute has value 48. However, since these facts are all implicit in the mechanism, there is no need to specify any of them.

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure both indicate 48 bytes.

Master key derivation

Master key derivation in SSL 3.0, denoted CKM_SSL3_MASTER_KEY_DERIVE, is a mechanism used to derive one 48-byte generic secret key from another 48-byte generic secret key. It is used to produce the "master_secret" key used in the SSL protocol from the "pre_master" key. This mechanism returns the value of the client version found in the "pre_master" key as well as a handle to the derived "master_secret" key.

It has a parameter, a CK_SSL3_MASTER_KEY_DERIVE_PARAMS structure, which allows for the passing of random data to the token as well as the returning of the protocol version number which is part of the pre-master key. This structure is defined in Section .

This mechanism has the following rules about key sensitivity and extractability:

The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key can both be specified to be either TRUE or FALSE. If omitted, these attributes each take on some default value.
If the base key has its CKA_ALWAYS_SENSITIVE attribute set to FALSE, then the derived key will as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its CKA_SENSITIVE attribute.
Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to FALSE, then the derived key will, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute. For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure both indicate 48 bytes.

Key and MAC derivation

Key, MAC and IV derivation in SSL 3.0, denoted CKM_SSL3_KEY_AND_MAC_DERIVE, is a mechanism is used to derive the appropriate cryptographic keying material used by a "CipherSuite" from the "master_secret" key and random data. This mechanism returns the key handles for the keys generated in the process, as well as the initialization vectors (IVs) created.

It has a parameter, a CK_SSL3_KEY_MAT_PARAMS structure, which allows for the passing of random data as well as the characteristic of the cryptographic material for the given CipherSuite and a pointer to a structure which receives the handles and IVs which were generated. This structure is defined in Section .

This mechanism contributes to the creation of four distinct keys on the token and returns two IVs (if IVs are requested by the caller) back to the caller. The keys are all given an object class of CKO_SECRET_KEY.

The two MACing keys ("client_write_MAC_secret" and "server_write_MAC_secret") are always given a type of CKK_GENERIC_SECRET. They are flagged as valid for signing, verification (they are used for MACing), and derivation operations.

The other two keys ("client_write_key" and "server_write_key") are typed according to information found in the template sent along with this mechanism during a C_DeriveKey function call. By default, they are flagged as valid for encryption, decryption, and derivation operations.

All four keys inherit the values of the CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE, and CKA_NEVER_EXTRACTABLE attributes from the base key. The template provided to C_DeriveKey may not specify values for any of these attributes which differ from those held by the base key.

Note that the CK_SSL3_KEY_MAT_OUT structure pointed to by the CK_SSL3_KEY_MAT_PARAMS structure's pReturnedKeyMaterial field will by modified by the C_DeriveKey call; in particular, the four key handle fields in the CK_SSL3_KEY_MAT_OUT structure will be modified to hold handles to the newly-created keys. In addition, the buffers pointed to by the CK_SSL3_KEY_MAT_OUT structure's pIVClient and pIVServer fields will have IVs returned in them (if IVs are requested by the caller). Therefore, these two fields must point to buffers with sufficient space to hold any IVs that will be returned.

This mechanism departs from the other key derivation mechanisms in Cryptoki in its returned information. For other mechanisms, the C_DeriveKey function returns a single key handle as a result of a successful completion. However, since the CKM_SSL3_KEY_AND_MAC_DERIVE mechanism returns all of its key handles in the CK_SSL3_KEY_MAT_OUT structure pointed to by the CK_SSL3_KEY_MAT_PARAMS structure specified as the mechanism parameter, the parameter phKey passed to C_DeriveKey is unnecessary, and should be a NULL_PTR.

If a call to C_DeriveKey with this mechanism fails, then none of the four keys will be created on the token.

MD5 MACing in SSL 3.0

MD5 MACing in SSL3.0, denoted CKM_SSL3_MD5_MAC, is a mechanism for single- and multiple-part signatures (data authentication) and verification using MD5, based on the SSL 3.0 protocol. This technique is very similar to the HMAC technique.

It has a parameter, a CK_MAC_GENERAL_PARAMS, which specifies the length in bytes of the signatures produced by this mechanism.

Constraints on key types and the length of input and output data are summarized in the following table:

Table 10-50, MD5 MACing in SSL 3.0: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign generic secret any 4-8, depending on parameters

C_Verify generic secret any 4-8, depending on parameters

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of generic secret key sizes, in bits.

SHA-1 MACing in SSL 3.0

SHA-1 MACing in SSL3.0, denoted CKM_SSL3_SHA1_MAC, is a mechanism for single- and multiple-part signatures (data authentication) and verification using SHA-1, based on the SSL 3.0 protocol. This technique is very similar to the HMAC technique.

It has a parameter, a CK_MAC_GENERAL_PARAMS, which specifies the length in bytes of the signatures produced by this mechanism.

Constraints on key types and the length of input and output data are summarized in the following table:

Table 10-51, SHA-1 MACing in SSL 3.0: Key And Data Length Constraints
Function Key type Data length Signature length

C_Sign generic secret any 4-8, depending on parameters

C_Verify generic secret any 4-8, depending on parameters

For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the supported range of generic secret key sizes, in bits.

Parameters for miscellaneous simple key derivation mechanisms

CK_KEY_DERIVATION_STRING_DATA

CK_KEY_DERIVATION_STRING_DATA is a structure that holds a pointer to a byte string and the byte string's length. It provides the parameters for the CKM_CONCATENATE_BASE_AND_DATA, CKM_CONCATENATE_DATA_AND_BASE, and CKM_XOR_BASE_AND_DATA mechanisms. It is defined as follows:

typedef struct CK_KEY_DERIVATION_STRING_DATA {
CK_BYTE_PTR pData;
CK_ULONG ulLen;
} CK_KEY_DERIVATION_STRING_DATA;

pData pointer to the byte string

ulLen length of the byte string
CK_KEY_DERIVATION_STRING_DATA_PTR

CK_KEY_DERIVATION_STRING_DATA_PTR points to a CK_KEY_DERIVATION_STRING_DATA structure. It is implementation-dependent.

CK_EXTRACT_PARAMS

CK_KEY_EXTRACT_PARAMS provides the parameter to the CKM_EXTRACT_KEY_FROM_KEY mechanism. It specifies which bit of the base key should be used as the first bit of the derived key. It is defined as follows:

typedef CK_ULONG CK_EXTRACT_PARAMS;

CK_EXTRACT_PARAMS_PTR

CK_EXTRACT_PARAMS_PTR points to a CK_EXTRACT_PARAMS. It is implemenation-dependent.

Miscellaneous simple key derivation mechanisms

Concatenation of a base key and another key

This mechanism, denoted CKM_CONCATENATE_BASE_AND_KEY, derives a secret key from the concatenation of two existing secret keys. The two keys are specified by handles; the values of the keys specified are concatenated together in a buffer.

This mechanism takes a parameter, a CK_OBJECT_HANDLE. This handle produces the key value information which is appended to the end of the base key's value information (the base key is the key whose handle is supplied as an argument to C_DeriveKey).

For example, if the value of the base key is 0x01234567, and the value of the other key is 0x89ABCDEF, then the value of the derived key will be taken from a buffer containing the string 0x0123456789ABCDEF.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be equal to the sum of the lengths of the values of the two original keys.
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length is provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more bytes than are available by concatenating the two original keys' values, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

If either of the two original keys has its CKA_SENSITIVE attribute set to TRUE, so does the derived key. If not, then the derived key's CKA_SENSITIVE attribute is set either from the supplied template or from a default value.
Similarly, if either of the two original keys has its CKA_EXTRACTABLE attribute set to FALSE, so does the derived key. If not, then the derived key's CKA_EXTRACTABLE attribute is set either from the supplied template or from a default value.
The derived key's CKA_ALWAYS_SENSITIVE attribute is set to TRUE if and only if both of the original keys have their CKA_ALWAYS_SENSITIVE attributes set to TRUE.
Similarly, the derived key's CKA_NEVER_EXTRACTABLE attribute is set to TRUE if and only if both of the original keys have their CKA_NEVER_EXTRACTABLE attributes set to TRUE. Concatenation of a base key and data

This mechanism, denoted CKM_CONCATENATE_BASE_AND_DATA, derives a secret key by concatenating data onto the end of a specified secret key.

This mechanism takes a parameter, a CK_KEY_DERIVATION_STRING_DATA structure, which specifies the length and value of the data which will be appended to the base key to derive another key.

For example, if the value of the base key is 0x01234567, and the value of the data is 0x89ABCDEF, then the value of the derived key will be taken from a buffer containing the string 0x0123456789ABCDEF.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be equal to the sum of the lengths of the value of the original key and the data.
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length is provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more bytes than are available by concatenating the original key's value and the data, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

If the base key has its CKA_SENSITIVE attribute set to TRUE, so does the derived key. If not, then the derived key's CKA_SENSITIVE attribute is set either from the supplied template or from a default value.
Similarly, if the base key has its CKA_EXTRACTABLE attribute set to FALSE, so does the derived key. If not, then the derived key's CKA_EXTRACTABLE attribute is set either from the supplied template or from a default value.
The derived key's CKA_ALWAYS_SENSITIVE attribute is set to TRUE if and only if the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE.
Similarly, the derived key's CKA_NEVER_EXTRACTABLE attribute is set to TRUE if and only if the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE. Concatenation of data and a base key

This mechanism, denoted CKM_CONCATENATE_DATA_AND_BASE, derives a secret key by prependting data to the start of a specified secret key.

This mechanism takes a parameter, a CK_KEY_DERIVATION_STRING_DATA structure, which specifies the length and value of the data which will be prepended to the base key to derive another key.

For example, if the value of the base key is 0x01234567, and the value of the data is 0x89ABCDEF, then the value of the derived key will be taken from a buffer containing the string 0x89ABCDEF01234567.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be equal to the sum of the lengths of the data and the value of the original key.
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length is provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more bytes than are available by concatenating the data and the original key's value, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

If the base key has its CKA_SENSITIVE attribute set to TRUE, so does the derived key. If not, then the derived key's CKA_SENSITIVE attribute is set either from the supplied template or from a default value.
Similarly, if the base key has its CKA_EXTRACTABLE attribute set to FALSE, so does the derived key. If not, then the derived key's CKA_EXTRACTABLE attribute is set either from the supplied template or from a default value.
The derived key's CKA_ALWAYS_SENSITIVE attribute is set to TRUE if and only if the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE.
Similarly, the derived key's CKA_NEVER_EXTRACTABLE attribute is set to TRUE if and only if the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE. XORing of a key and data

XORing key derivation, denoted CKM_XOR_BASE_AND_DATA, is a mechanism which provides the capability of deriving a secret key by performing a bit XORing of a key pointed to by a base key handle and some data.

This mechanism takes a parameter, a CK_KEY_DERIVATION_STRING_DATA structure, which specifies the data with which to XOR the original key's value.

For example, if the value of the base key is 0x01234567, and the value of the data is 0x89ABCDEF, then the value of the derived key will be taken from a buffer containing the string 0x88888888.

If no length or key type is provided in the template, then the key produced by this mechanism will be a generic secret key. Its length will be equal to the minimum of the lengths of the data and the value of the original key.
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length is provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more bytes than are available by taking the shorter of the data and the original key's value, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

If the base key has its CKA_SENSITIVE attribute set to TRUE, so does the derived key. If not, then the derived key's CKA_SENSITIVE attribute is set either from the supplied template or from a default value.
Similarly, if the base key has its CKA_EXTRACTABLE attribute set to FALSE, so does the derived key. If not, then the derived key's CKA_EXTRACTABLE attribute is set either from the supplied template or from a default value.
The derived key's CKA_ALWAYS_SENSITIVE attribute is set to TRUE if and only if the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE.
Similarly, the derived key's CKA_NEVER_EXTRACTABLE attribute is set to TRUE if and only if the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE. Extraction of one key from another key

Extraction of one key from another key, denoted CKM_EXTRACT_KEY_FROM_KEY, is a mechanism which provides the capability of creating one secret key from the bits of another secret key.

This mechanism has a parameter, a CK_EXTRACT_PARAMS, which specifies which bit of the original key should be used as the first bit of the newly-derived key.

We give an example of how this mechanism works. Suppose a token has a secret key with the 4-byte value 0x329F84A9. We will derive a 2-byte secret key from this key, starting at bit position 21 (i.e., the value of the parameter to the CKM_EXTRACT_KEY_FROM_KEY mechanism is 21).

We write the key's value in binary: 0011 0010 1001 1111 1000 0100 1010 1001. We regard this binary string as holding the 32 bits of the key, labelled as b₀, b₁, ..., b₃₁.
We then extract 16 consecutive bits (i.e., 2 bytes) from this binary string, starting at bit b₂₁. We obtain the binary string 1001 0101 0010 0110.
The value of the new key is thus 0x9526.

Note that when constructing the value of the derived key, it is permissible to wrap around the end of the binary string representing the original key's value.

If the original key used in this process is sensitive, then the derived key must also be sensitive for the derivation to succeed.

If no length or key type is provided in the template, then an error will be returned.
If no key type is provided in the template, but a length is, then the key produced by this mechanism will be a generic secret key of the specified length.
If no length is provided in the template, but a key type is, then that key type must have a well-defined length. If it does, then the key produced by this mechanism will be of the type specified in the template. If it doesn't, an error will be returned.
If both a key type and a length are provided in the template, the length must be compatible with that key type. The key produced by this mechanism will be of the specified type and length. If a DES, DES2, DES3, or CDMF key is derived with this mechanism, the parity bits of the key will be set properly.

If the requested type of key requires more bytes than the original key has, an error is generated.

This mechanism has the following rules about key sensitivity and extractability:

If the base key has its CKA_SENSITIVE attribute set to TRUE, so does the derived key. If not, then the derived key's CKA_SENSITIVE attribute is set either from the supplied template or from a default value.
Similarly, if the base key has its CKA_EXTRACTABLE attribute set to FALSE, so does the derived key. If not, then the derived key's CKA_EXTRACTABLE attribute is set either from the supplied template or from a default value.
The derived key's CKA_ALWAYS_SENSITIVE attribute is set to TRUE if and only if the base key has its CKA_ALWAYS_SENSITIVE attribute set to TRUE.
Similarly, the derived key's CKA_NEVER_EXTRACTABLE attribute is set to TRUE if and only if the base key has its CKA_NEVER_EXTRACTABLE attribute set to TRUE.

RSA Security Inc. Public-Key Cryptography Standards - PKCS#11 - v200

	Functions
Mechanism	Encrypt & Decrypt	Sign & Verify	SR & VR ¹	Digest	Gen. Key/ Key Pair	Wrap & Unwrap	Derive
CKM_RSA_PKCS_KEY_PAIR_GEN					X
CKM_RSA_PKCS	X²	X²	X			X
CKM_RSA_9796		X²	X
CKM_RSA_X_509	X²	X²	X			X
CKM_MD2_RSA_PKCS	X	X
CKM_MD5_RSA_PKCS	X	X
CKM_SHA1_RSA_PKCS	X	X
CKM_DSA_KEY_PAIR_GEN					X
CKM_DSA		X²
CKM_DSA_SHA1		X
CKM_FORTEZZA_TIMESTAMP		X²
CKM_ECDSA_KEY_PAIR_GEN					X
CKM_ECDSA		X²
CKM_ECDSA_SHA1		X
CKM_DH_PKCS_KEY_PAIR_GEN					X
CKM_DH_PKCS_DERIVE							X
CKM_KEA_KEY_PAIR_GEN					X
CKM_KEA_KEY_DERIVE							X
CKM_MAYFLY_KEY_PAIR_GEN					X
CKM_MAYFLY_KEY_DERIVE							X
CKM_GENERIC_SECRET_KEY_GEN					X
CKM_RC2_KEY_GEN					X
CKM_RC2_ECB	X					X
CKM_RC2_CBC	X					X
CKM_RC2_CBC_PAD	X					X
CKM_RC2_MAC_GENERAL		X
CKM_RC2_MAC		X
CKM_RC4_KEY_GEN					X
CKM_RC4	X
CKM_RC5_KEY_GEN					X
CKM_RC5_ECB	X					X
CKM_RC5_CBC	X					X
CKM_RC5_CBC_PAD	X					X
CKM_RC5_MAC_GENERAL		X
CKM_RC5_MAC		X
CKM_DES_KEY_GEN					X
CKM_DES_ECB	X					X
CKM_DES_CBC	X					X
CKM_DES_CBC_PAD	X					X
CKM_DES_MAC_GENERAL		X
CKM_DES_MAC		X
CKM_DES2_KEY_GEN					X
CKM_DES3_KEY_GEN					X
CKM_DES3_ECB	X					X
CKM_DES3_CBC	X					X
CKM_DES3_CBC_PAD	X					X
CKM_DES3_MAC_GENERAL		X
CKM_DES3_MAC		X
CKM_CAST_KEY_GEN					X
CKM_CAST_ECB	X					X
CKM_CAST_CBC	X					X
CKM_CAST_CBC_PAD	X					X
CKM_CAST_MAC_GENERAL		X
CKM_CAST_MAC		X
CKM_CAST3_KEY_GEN					X
CKM_CAST3_ECB	X					X
CKM_CAST3_CBC	X					X
CKM_CAST3_CBC_PAD	X					X
CKM_CAST3_MAC_GENERAL		X
CKM_CAST3_MAC		X
CKM_CAST5_KEY_GEN					X
CKM_CAST5_ECB	X					X
CKM_CAST5_CBC	X					X
CKM_CAST5_CBC_PAD	X					X
CKM_CAST5_MAC_GENERAL		X
CKM_CAST5_MAC		X
CKM_IDEA_KEY_GEN					X
CKM_IDEA_ECB	X					X
CKM_IDEA_CBC	X					X
CKM_IDEA_CBC_PAD	X					X
CKM_IDEA_MAC_GENERAL		X
CKM_IDEA_MAC		X
CKM_CDMF_KEY_GEN					X
CKM_CDMF_ECB	X					X
CKM_CDMF_CBC	X					X
CKM_CDMF_CBC_PAD	X					X
CKM_CDMF_MAC_GENERAL		X
CKM_CDMF_MAC		X
CKM_SKIPJACK_KEY_GEN					X
CKM_SKIPJACK_ECB64	X
CKM_SKIPJACK_CBC64	X
CKM_SKIPJACK_OFB64	X
CKM_SKIPJACK_CFB64	X
CKM_SKIPJACK_CFB32	X
CKM_SKIPJACK_CFB16	X
CKM_SKIPJACK_CFB8	X
CKM_SKIPJACK_WRAP						X
CKM_SKIPJACK_PRIVATE_WRAP						X
CKM_SKIPJACK_RELAYX						X³
CKM_BATON_KEY_GEN					X
CKM_BATON_ECB128	X
CKM_BATON_ECB96	X
CKM_BATON_CBC128	X
CKM_BATON_COUNTER	X
CKM_BATON_SHUFFLE	X
CKM_BATON_WRAP						X
CKM_JUNIPER_KEY_GEN					X
CKM_JUNIPER_ECB128	X
CKM_JUNIPER_CBC128	X
CKM_JUNIPER_COUNTER	X
CKM_JUNIPER_SHUFFLE	X
CKM_JUNIPER_WRAP						X
CKM_MD2				X
CKM_MD2_HMAC_GENERAL		X
CKM_MD2_HMAC		X
CKM_MD2_KEY_DERIVATION							X
CKM_MD5				X
CKM_MD5_HMAC_GENERAL		X
CKM_MD5_HMAC		X
CKM_MD5_KEY_DERIVATION							X
CKM_SHA_1				X
CKM_SHA_1_HMAC_GENERAL		X
CKM_SHA_1_HMAC		X
CKM_SHA1_KEY_DERIVATION							X
CKM_FASTHASH				X
CKM_PBE_MD2_DES_CBC					X
CKM_PBE_MD5_DES_CBC					X
CKM_PBE_MD5_CAST_CBC					X
CKM_PBE_MD5_CAST3_CBC					X
CKM_PBE_MD5_CAST5_CBC					X
CKM_KEY_WRAP_SET_OAEP						X
CKM_KEY_WRAP_LYNKS						X
CKM_SSL3_PRE_MASTER_KEY_GEN					X
CKM_SSL3_MASTER_KEY_DERIVE							X
CKM_SSL3_KEY_AND_MAC_DERIVE							X
CKM_SSL3_MD5_MAC		X
CKM_SSL3_SHA1_MAC		X
CKM_CONCATENATE_BASE_AND_KEY							X
CKM_CONCATENATE_BASE_AND_DATA							X
CKM_CONCATENATE_DATA_AND_BASE							X
CKM_XOR_BASE_AND_DATA							X
CKM_EXTRACT_KEY_FROM_KEY							X

Function	Key type	Input length	Output length	Comments
C_Encrypt¹	RSA public key	<= k -11	k	block type 02
C_Decrypt¹	RSA private key	k	<= k -11	block type 02
C_Sign¹	RSA private key	<= k -11	k	block type 01
C_SignRecover	RSA private key	<= k -11	k	block type 01
C_Verify¹	RSA public key	<= k -11, k ²	N/A	block type 01
C_VerifyRecover	RSA public key	k	<= k -11	block type 01
C_WrapKey	RSA public key	<= k -11	k	block type 02
C_UnwrapKey	RSA private key	k	<= k -11	block type 02

isSender	Option for generating the key (called a TEK). The value is TRUE if the sender (originator) generates the TEK, FALSE if the recipient is regenerating the TEK.
ulRandomLen	size of random Ra and Rb, in bytes
pRandomA	pointer to Ra data
pRandomB	pointer to Rb data
ulPublicDataLen	other party's KEA public key size
pPublicData	pointer to other party's KEA public key value CK_KEA_DERIVE_PARAMS_PTR

ulEffectiveBits	the effective number of bits in the RC2 search space
iv	the initialization vector (IV) for cipher block chaining mode CK_RC2_CBC_PARAMS_PTR

ulEffectiveBits	the effective number of bits in the RC2 search space
ulMacLength	length of the MAC produced, in bytes CK_RC2_MAC_GENERAL_PARAMS_PTR

Function	Key type	Data length	Signature length
C_Sign	RC2	any	0-8, as specified in parameters
C_Verify	RC2	any	0-8, as specified in parameters

ulWordsize	wordsize of RC5 cipher in bytes
ulRounds	number of rounds of RC5 encipherment CK_RC5_PARAMS_PTR

ulPasswordLen	length of the password
pPassword	pointer to the buffer which contains the user-supplied password
ulPublicDataLen	other party's key exchange public key size
pPublicData	pointer to other party's key exchange public key value
ulPandGLen	length of prime and base values
ulQLen	length of subprime value
ulRandomLen	size of random Ra, in bytes
pRandomA	pointer to Ra data
pPrimeP	pointer to Prime, p, value
pBaseG	pointer to Base, g, value
pSubprimeQ	pointer to Subprime, q, value CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR

ulOldWrappedXLen	length of old wrapped key in bytes
pOldWrappedX	pointer to old wrapper key
ulOldPasswordLen	length of the old password
pOldPassword	pointer to the buffer which contains the old user-supplied password
ulOldPublicDataLen	old key exchange public key size
pOldPublicData	pointer to old key exchange public key value
ulOldRandomLen	size of old random Ra in bytes
pOldRandomA	pointer to old Ra data
ulNewPasswordLen	length of the new password
pNewPassword	pointer to the buffer which contains the new user-supplied password
ulNewPublicDataLen	new key exchange public key size
pNewPublicData	pointer to new key exchange public key value
ulNewRandomLen	size of new random Ra in bytes
pNewRandomA	pointer to new Ra data CK_SKIPJACK_RELAYX_PARAMS_PTR

pInitVector	pointer to the location that receives the 8-byte initialization vector (IV);
pPassword	points to the password to be used in the PBE key generation;
ulPasswordLen	length in bytes of the password information;
pSalt	points to the salt to be used in the PBE key generation;
usSaltLen	length in bytes of the salt information;
usIteration	number of iterations required for the generation. CK_PBE_PARAMS_PTR

bBC	block contents byte
pX	extra data
ulXLen	length in bytes of extra data CK_KEY_WRAP_SET_OAEP_PARAMS_PTR

pClientRandom	pointer to the client's random data. (see SSL 3.0 for details)
ulClientRandomLen	length in bytes of the client's random data
pServerRandom	pointer to the server's random data. (see SSL 3.0 for details)
ulServerRandomLen	length in bytes of the server's random data CK_SSL3_MASTER_KEY_DERIVE_PARAMS

RandomInfo	client's and server's random data information.
pVersion	pointer to a '''CK_VERSION '''structure which receives the SSL protocol version information (see SSL 3.0 for details) CK_SSL3_MASTER_KEY_DERIVE_PARAMS_PTR

hClientMacSecret	key handle for the resulting Client MAC Secret key
hServerMacSecret	key handle for the resulting Server MAC Secret key
hClientKey	key handle for the resulting Client Secret key
hServerKey	key handle for the resulting Server Secret key
pIVClient	pointer to a location which receives the initialization vector (IV) created for the client, if any (see SSL 3.0 for details)
pIVServer	pointer to a location which receives the initialization vector (IV) created for the server, if any (see SSL 3.0 for details) CK_SSL3_KEY_MAT_OUT_PTR

ulMacSizeInBits	establishes the length (in bits) of the MACing keys agreed upon during the protocol handshake phase (see SSL 3.0 for details)
ulKeySizeInBits	establishes the length (in bits) of the secret keys agreed upon during the protocol handshake phase (see SSL 3.0 for details)
ulIVSizeInBits	establishes the length (in bits) of the IV agreed upon during the protocol handshake phase. If no IV is required, the length should be set to 0 (see SSL 3.0 for details)
bIsExport	a boolean value which indicates whether the keys have to be derived for an export version of the protocol (see SSL 3.0 for details)
RandomInfo	client's and server's random data information.
pReturnedKeyMaterial	points to a '''CK_SSL3_KEY_MAT_OUT''' structures which receives the handles for the keys generated, as well as the IVs when required (see SSL 3.0 for details) CK_SSL3_KEY_MAT_PARAMS_PTR