PKA Decrypt (CSNDPKD)
Use this verb to decrypt (unwrap) a formatted key value. This verb unwraps the key, parses it, and returns the parsed value to the application in the clear.
PKCS 1.2, PKCSOAEP, PKOAEP2, and ZERO-PAD formatting are supported. For PKCS 1.2, the decrypted data is examined to ensure that it meets RSA DSI PKCS #1 block type 2 format specifications. ZERO-PAD is only supported for external or clear RSA private keys or PQC keys (CRYSTALS-Kyber or ML-KEM keys).
For the PKCSOAEP or PKOAEP2 recovery method keyword, the decrypted data is examined to ensure that it meets the RSAES-OAEP scheme of the RSA PKCS #1 v2.0 or RSAPKCS #1 v2.1 standard respectively. See also PKCS #1 hash formats.
For PKA private keys, this verb allows the use of clear or encrypted RSA private keys or PQC private keys. If an external clear key token is used, the master keys are not required to be installed in any cryptographic coprocessor and PKA verbs do not have to be enabled.
The ZERO-PAD keyword is required when using a PQC key ( CRYSTALS-Kyber or ML-KEM key).
A rule group Key format is provided for ML-KEM keys. This rule determines how the 32 byte decrypted key is returned. If no rule is provided, the key is returned in the clear.
AES-KB is used during a key establishment process between two parties over an insecure network. The first party uses their ML-KEM public key to encrypt an AES key. The ML-KEM encrypted AES key is transmitted to the second party who uses their private key to decrypt the ciphertext to obtain the clear AES key. After this procedure both parties have a shared symmetric key.
If AES-KB is selected, the caller must provide an AES skeleton key token. The attributes of this token are copied to the key token that gets generated with CSNDPKD. This key token must be an internal AES key with either the ENCRYPT or DERYPT, or both key usage fields on.