OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Behavior of C_Decrypt in pkcs#11

Hi all,

I want to suggest that the behavior of theÂC_Decryptfunction should be more clearly defined in the pkcs#11 standard. My observation arises from testing with several HSM brands, where I noticed an inconsistency when using symmetric key mechanisms that return variable length output, such as theÂCKM_AES_CBC_PADÂmechanism.Â

To illustrate my point I shall give an example: suppose that I have a 272 bytes long ciphertext, which I know should actually decrypt to 256 bytes via theÂCKM_AES_CBC_PADÂmechanism, which means a full block of padding was added. (I know this because I originally encrypted 256 bytes via the same mechanism).

I know thatÂaccording to the standardÂwhen invokingÂC_DecryptÂwith a NULL output buffer the function may return an output length which is somewhat longer than the actual required length, in particular when padding is used this is understandable, as the function can't know how many padding bytes are in the final block without carrying out the actual decryption. But there's nothing in the standard states that it is necessary when I *do* know what output length to expect, which is the use case I am describing.

So what I noticed is that some HSMs will successfully return exactly 256 bytes back as a response to a C_Decrypt for such a ciphertext, while others will return aÂCKR_BUFFER_TOO_SMALLÂerror as a result. I guess that the implementations which return this error just don't allocate an internal buffer for the final block which contains the padding, to actually check its contents and how much padding bytes are there. Without doing that it would be natural to require more bytes in the output buffer than they may actually need.Â

So I think that the issue with the standard is that there's no clear requirement to make a call with a NULL output buffer to C_Decrypt before invoking it with a real buffer - so that some implementations seem to assume you have done both while others are more conservative, resulting in the inconsistency I described.

If this issue can be either clarified (I may be misunderstanding something about the standard) or perhaps addressed in a future version of pkcs#11, that would be of great help.

Best Regards,



P.S. I posted a question with a similar pharsing a while ago in the SO site:Âhttps://stackoverflow.com/questions/56818371/what-is-the-correct-behavior-of-c-decrypt-in-pkcs11ÂÂ

but so far got no satisfactory answer.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]