CKR_ENCRYPTED_DATA_INVALID

What the token is reporting

The ciphertext could not be turned into something the mechanism accepts. The key is of the right type and the operation ran, so the fault is in the data or in the key’s value.

Likely causes

Ordered by how often they turn out to be the answer. That ordering is a judgement from experience, not a measured frequency.

A different key from the one that encrypted

A rotated key, a key with the same label in a different slot, a derived key made with slightly different inputs. The decrypt succeeds mathematically and produces bytes whose padding or tag fails, and the code is identical to corrupted data.

Check it: Encrypt a known value with the key you believe was used and compare with the ciphertext in hand. A check value attribute, where the token supports it, identifies the key without decrypting anything.

Padding mismatch between the two sides

Encrypted with the padded CBC mechanism and decrypted with the raw one, OAEP with a different hash on each side, OAEP on one side and PKCS#1 v1.5 on the other. The block cipher does not care and the padding check does.

Check it: Find out which mechanism and which parameters produced the ciphertext, rather than assuming they match yours.

Truncated or altered ciphertext, or a tag in the wrong place

For an authenticated mode the tag has to arrive with the ciphertext, and libraries differ on whether it is appended or separate. A base64 round trip that lost a byte, a length off by one block, or a tag length in the parameters that does not match the bytes all land here.

Check it: Compare the ciphertext length with what the encryptor produced, and for an authenticated mode compare the tag length in the parameters with the bytes you appended.

The channel between library and device, not your ciphertext

One library maps failures of its own secure channel to the device, an authentication or MAC mismatch, onto this code. The failing call may not be a decrypt at all.

Check it: Turn on the library’s debug log and look for a native session or MAC error before the return.

Which calls return it

C_Decrypt, C_DecryptUpdate, C_DecryptFinal, C_UnwrapKey

What it is not

It is not the length, which has its own encrypted-data variant, and not a signature failure. Both of those mean something different went wrong before or instead of the decryption.

Often confused with

• CKR_ENCRYPTED_DATA_LEN_RANGE: The count was wrong and the decrypt never ran. This code means it ran.
• CKR_DATA_INVALID: The same idea on the encrypt and sign side.
• CKR_AEAD_DECRYPT_FAILED: The newer, precise code for a failed authentication tag, on libraries that have adopted it.

By library

SoftHSMv2

Returned when a symmetric decrypt update or final fails and when an asymmetric decrypt fails, and the operation is reset each time (SoftH SM.cpp), so the call after this one gets operation not initialised.

IBM opencryptoki

PKCS#1 block parsing checks the leading zero, the block type, the separator and the padding length and reports each as this code (mech_ rsa.c). On RSA decrypt a length error from the token layer is rewritten to this code in constant time (mech_rsa.c), and the OAEP result is selected the same way. The intent is that a caller cannot tell padding failures apart by return code.

OpenSC

The card’s wrong-padding error becomes this code (misc.c).

YubiHSM 2

Three of the library’s own errors map here: a cryptogram mismatch, a session authentication failure and a MAC mismatch on the secure channel (util_pkcs11.c). From a YubiHSM this code can mean the channel and not your data.

Sources

• PKCS #11 Specification Version 3.2, OASIS. Read 2026-09-10. Used for constant name and numeric value.

Every description, cause and check on this page is written from scratch. The specification is cited for the constant's name and its number, which are facts, and for nothing else.