On Thu, 25 Mar 2021 22:13:42 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> Hi, >> >> I'd like to propose a fix for JDK-8261355 [1]. >> >> The scheme used for holding data and padding while performing encryption >> operations is almost the same than the existing one for decryption. The only >> difference is that encryption does not require a block-sized buffer to be >> always held because there is no need, upon an update call, to determine >> which bytes are real output for the caller and which are padding -as it's >> required for decryption-. I added a couple of comments in implUpdate to >> explain this. >> >> No regressions observed in jdk/sun/security/pkcs11. >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 > > Martin Balao has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > > - 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 265: > 263: // NSS requires block-sized updates in multi-part > operations. > 264: reqBlockUpdates = ((tokenLabel[0] == 'N' && > tokenLabel[1] == 'S' > 265: && tokenLabel[2] == 'S') ? true : false); IIRC, depending on how the impl is registered, engineSetPadding(String) may not always be called. It's probably safer to set this in engineInit(...)? ------------- PR: https://git.openjdk.java.net/jdk/pull/2510