8305091: Change ChaCha20 cipher init behavior to match AES-GCM

[jnimeh]

This fixes an issue where the key/nonce reuse policy for SunJCE ChaCha20 and ChaCha20-Poly1305 was overly strict in enforcing no-reuse when the Cipher was in DECRYPT_MODE. For decryption, this should be allowed and be consistent with the AES-GCM decryption initialization behavior.

• Issue: https://bugs.openjdk.org/browse/JDK-8305091
• CSR: https://bugs.openjdk.org/browse/JDK-8305822

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Change requires CSR request JDK-8305822 to be approved
• Commit message must refer to an issue

Issues

• JDK-8305091: Change ChaCha20 cipher init behavior to match AES-GCM
• JDK-8305822: Change ChaCha20 cipher init behavior to match AES-GCM (CSR)

Reviewers

• Daniel Jeliński (@djelinski - Reviewer)
• Anthony Scarpino (@ascarpino - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13428/head:pull/13428
$ git checkout pull/13428

Update a local copy of the PR:
$ git checkout pull/13428
$ git pull https://git.openjdk.org/jdk.git pull/13428/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13428

View PR using the GUI difftool:
$ git pr show -t 13428

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13428.diff

Webrev

Link to Webrev Comment

[jnimeh]

/csr needed

[jnimeh]

/issue 8305091

[bridgekeeper]

👋 Welcome back jnimeh! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jnimeh an approved CSR request is already required for this pull request.

[openjdk]

@jnimeh This issue is referenced in the PR title - it will now be updated.

[openjdk]

@jnimeh The following label will be automatically applied to this pull request:

• security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (609c3419)

[bridgekeeper]

@jnimeh This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[djelinski]

Thank you for that. This is actually required for decrypting QUIC packets; the QUIC specification permits dropping duplicate packets only after fully decrypting them.

LGTM.

[XueleiFan]

the QUIC specification permits dropping duplicate packets only after fully decrypting them.

May I have a reference, for example the section number, of the specification?

[djelinski]

Here you go:
https://www.rfc-editor.org/rfc/rfc9000.html#name-packet-numbers

A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. Duplicate suppression MUST happen after removing packet protection for the reasons described in Section 9.5 of [QUIC-TLS].

https://www.rfc-editor.org/rfc/rfc9001#section-9.5

If the recipient of a packet discards packets with duplicate packet numbers without attempting to remove packet protection, they could reveal through timing side channels that the packet number matches a received packet. For authentication to be free from side channels, the entire process of header protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side channels.

Additionally check out the header protection section https://www.rfc-editor.org/rfc/rfc9001#name-chacha20-based-header-prote:

  header_protection(hp_key, sample):
  counter = sample[0..3]
  nonce = sample[4..15]
  mask = ChaCha20(hp_key, counter, nonce, {0,0,0,0,0})

sample is taken from encrypted data, so basically random; there's a (minimal) chance that the sample will be the same between unrelated packets, and a 100% chance that duplicate packets will have the same sample. Without this PR, header protection fails on duplicate samples. With this PR ChaCha20 is usable (in decrypt mode, but both modes produce identical output)

[XueleiFan]

Here you go:

@djelinski Thank you!

[openjdk]

@jnimeh This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8305091: Change ChaCha20 cipher init behavior to match AES-GCM

Reviewed-by: djelinski, ascarpino

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 840 new commits pushed to the master branch:

• 5d8ba93: 8308046: Move Solaris related charsets from java.base to jdk.charsets module
• 878162b: 8306507: [linux] Print number of memory mappings in error reports
• 90d5041: 8300086: Replace NULL with nullptr in share/c1/
• 8474e69: 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
• f99ad11: 8302218: CHeapBitMap::free frees with incorrect size
• d77a410: 8308388: Update description of SourceVersion.RELEASE_21
• 3f4cfbd: 8307190: Refactor ref_at methods in Constant Pool
• 491bdea: 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
• b58980b: 8308034: Some CDS tests need to use @requires vm.flagless
• 29b8d3d: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
• ... and 830 more: https://git.openjdk.org/jdk/compare/a2d8f634de69d11d7beec5e853f710719497bfe3...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[jnimeh]

/integrate

[openjdk]

Going to push as commit bb0ff48.
Since your change was applied there have been 856 commits pushed to the master branch:

• c0c4d77: 8308544: Fix compilation regression from JDK-8306983 on musl libc
• 9e196b3: 8308565: HttpClient: Sanitize logging while stopping
• 582ddeb: 8308545: java/net/httpclient/ShutdownNow.java fails with "stream 1 cancelled"
• 1cfb265: 8307814: In the case of two methods with Record Patterns, the second one contains a line number from the first method
• eb11508: 8308281: Java snippets in the FFM API need to be updated
• 26227a6: 8305073: Fix VerifyLoopOptimizations - step 2 - verify idom
• 80d7de7: 8305582: Compiler crash when compiling record patterns with var
• e559613: 8308500: ZStatSubPhase::register_start should not call register_gc_phase_start if ZAbort::should_abort()
• bdd2402: 8260943: C2 SuperWord: Remove dead vectorization optimization added by 8076284
• 4f0f776: 8308403: [s390x] separate remaining_cargs from z_abi_160
• ... and 846 more: https://git.openjdk.org/jdk/compare/a2d8f634de69d11d7beec5e853f710719497bfe3...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jnimeh Pushed as commit bb0ff48.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.