Clarification on use of C_Encrypt() and C_Decrypt() with zero-length inputs.

[Jason King <jason.king@joyent.com>]

I encountered a bit of an interesting corner case that I’m unable to find any guidance on in the current version of the standard.  I’m hoping someone could either point me to the relevant portion, or clarify so I know where the error actually lies (PKCS#11 implementation or consuming code).

The underlying definitions of some mechanisms (e.g. padding variants, or combined mode ciphers if the optional ‘additional data’ is present)

It appears for some mechanisms (padded algorithms, or combined mode ciphers w/ ‘additional data’ included in the mechanism parameter during the C_{Encrypt,Decrypt}Init() call) it can be acceptable (at least according to the specifications of the underlying mechanism) to specify a zero-length input (either for encryption or decryption), however even in those situations, the C_Encrypt/Decrypt calls are failing with CKR_ARGUMENTS_BAD if pData is NULL (though if ulDataLen is 0, it seems odd to require a valid address to something you’re never going to deference).   It’s unclear that even when the underlying mechanism definition allows such things, if their use via PKCS#11 allows for it

Attachment: signature.asc
Description: Message signed with OpenPGP using AMPGpg