On Tue, 11 Apr 2023 18:15:22 GMT, Xue-Lei Andrew Fan <xue...@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 > > In the decryption side, does it sound like good to detect and reject > key/nonce reuse for security reason(i.e., if key/nonce is reused, the > decryption side will not accept the encryption)? Did you known real problems > in practice for the key/nonce reuse for decryption? @XueleiFan I think the key/nonce reuse protections are there to prevent sending ciphertexts out that are created from XORing against the same value twice. But that is an encryption use case. Decryption is a different story, since you're consuming the ciphertext and not emitting data out on the wire. The decrypting entity might use that data, but that doesn't leak information to a passive observer. There are cases where people using the ChaCha20 and ChaCha20-Poly1305 ciphers have run into behavioral issues because they operate differently than AES-GCM does. It seems sensible that the ciphers should be unified in their behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13428#issuecomment-1503878118
