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

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

Gah.. sorry about that — I was trying to edit for clarity and fat fingered the d@# Touch Bar send key.

So to try it again — the underlying definition of some ciphers (btw, the AES_GCM section references [GCM] but doesn’t appear in the list of references in the mechanism doc — so I’m not sure if you’re referring to an RFC or the NIST publication here) allow for empty input data (padding variants, combined mode ciphers).  What isn’t clear is if their use in PKCS#11 via C_Encrypt/Decrypt still require the pData to be set in such an instance.

From: Jason King <jason.king@joyent.com>
Date: January 26, 2018 at 11:05:22 AM
To: pkcs11-comment@lists.oasis-open.org <pkcs11-comment@lists.oasis-open.org>
Subject:  Clarification on use of C_Encrypt() and C_Decrypt() with zero-length inputs.

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