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

[Jamil Nimeh]

On Tue, 11 Apr 2023 18:15:22 GMT, Xue-Lei Andrew Fan <xuelei 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
>
> 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