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 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 819: > 817: int startOff = 0; > 818: if (reqBlockUpdates) { > 819: startOff = bytesBuffered; Shouldn't the starting offset be the number of bytes in padBuffer, i.e. padBufferLen? ------------- PR: https://git.openjdk.java.net/jdk/pull/2510