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