RFR: JDK-8280703 CipherCore.doFinal(...) causes potentially massive byte[] allocations during decryption
Sebastian Stenzel
duke at openjdk.java.net
Wed Jan 26 10:45:47 UTC 2022
Related to #411, however it turns out that for unpadded ciphers, there is no need to allocate `internalOutput`, if `output` provides sufficient capacity.
For padded ciphers, only the unpadded cleartext is expected to be copied to the output buffer. In this case, there is no way around the temporary buffer (without major changes).
While a small change, please review with care, as I might be missing some security-relevant side effect (such as: don't copy cleartext to output buffer before validating the a tag - just as an example, even if there is no authentication involved in this method).
I have some test failures in Tier 1 tests, but these seem to be unrelated. Tests for `com.sun.crypto` and `javax.crypto` run fine:
==============================
Test summary
==============================
TEST TOTAL PASS FAIL ERROR
jtreg:test/jdk/com/sun/crypto 141 141 0 0
jtreg:test/jdk/javax/crypto 56 56 0 0
==============================
TEST SUCCESS
-------------
Commit messages:
- keep using a temporary buffer for unpadding the cleartext
- only allocate internal buffer in case of insufficient output capacity
Changes: https://git.openjdk.java.net/jdk/pull/7230/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7230&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280703
Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
Patch: https://git.openjdk.java.net/jdk/pull/7230.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7230/head:pull/7230
PR: https://git.openjdk.java.net/jdk/pull/7230
More information about the security-dev
mailing list