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

Daniel Jeliński djelinski at openjdk.org
Thu May 18 18:19:52 UTC 2023


On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> 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

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](https://www.rfc-editor.org/rfc/rfc9001#section-9.5) of [[QUIC-TLS](https://www.rfc-editor.org/rfc/rfc9000.html#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 AES-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)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1553440682



More information about the security-dev mailing list