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 test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 68: > 66: ByteBuffer cipherText = > 67: ByteBuffer.allocate(((inputSize / 16 ) + 1) * 16); > 68: byte[] tmp = new byte[16]; Seems no need to do new byte[] given how it's used. test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java line 78: > 76: updateLength); > 77: if (tmp != null) > 78: cipherText.put(tmp); nit: either use "{ }" or move cipherText.put() call to the same line as if-check. ------------- PR: https://git.openjdk.java.net/jdk/pull/2510
