On Tue, 11 Apr 2023 17:26:25 GMT, Jamil Nimeh <jni...@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
