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

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 <>
Date: January 26, 2018 at 11:05:22 AM
To:  <>
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