RFR: 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding [v2]

[Martin Balao]

On Tue, 30 Mar 2021 21:19:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Avoid overriding buffered bytes with padding in the doFinal call.
>>  - Only do encryption block-size buffering for NSS
>>  - 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java line 639:
> 
>> 637:                     // returned to the caller. None of this is necessary for
>> 638:                     // encryption: encrypted data can be safely returned upon a
>> 639:                     // implUpdate call.
> 
> nit: all of the "unencrypted" -> "decrypted". I think this is a bit too verbose? Could we trim it down more, e.g. for decrypting with update() calls, up to a block of input is held inside padBuffer as it may contain padding bytes when no more data is supplied when doFinal() is called.
> 
> It should be clear that this does not apply for encryption, so there should be no need to state that.

I'll replace "unencrypted" with "decrypted" and remove the comment about this not being necessary for encryption. I've also trimmed and improved my comment a bit: "While decrypting with implUpdate, the current encrypted block is always held in a buffer. If it's the last one (unknown at this point), it may contain padding bytes and need further processing. In implDoFinal (where we know it's the last one) the buffer is decrypted, unpadded and returned.". One comment about your suggestion: it's block-sized, not 'up to a block size'. But sounded a bit confusing to me overall, so if possible I'd stick to something along the lines above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2510