Create an AEAD cipher SPI for ChaCha20-Poly1305 about o1c HOT 4 CLOSED

After implementing the two providers so far, once I actually started to use the cipher API in building the higher level APIs, I found that there may not be a need to facade over javax.crypto.Cipher due to the need for using many of its lower level update and doFinal methods. Since this cipher can be loaded and used in Java 8 (via BouncyCastle) or in Java 11+ natively, and since we don't need access to the ChaCha20ParameterSpec class added in Java 8 (this parameter spec is only useful for ChaCha20 and not ChaCha20-Poly1305 as the latter uses an implicit block counter rather than allowing it to be specified during initialization). It seems as though the awkward APIs are mostly concentrated in the other SPIs.

from o1c.

Oh no, it seems as though we have a slight problem. It sounds like the 96-bit nonces standardized in RFC 7539 might be too short for random nonces and long lived keys. While this may not be a problem for the use case in #5, if data in #4 are to be long-lived, then upgrading to XChaCha20-Poly1305 (fairly similar to XSalsa20-Poly1305 which already extended its nonce) would be more appropriate.

from o1c.

This seems to be about as explored as it will get. Only a thin wrapper around javax.crypto.Cipher is needed for convenience, and #4 provides the higher level API here. If XChaCha20-Poly1305 is added to more Java libraries, the added code to support it might be removable someday.

from o1c.

Reopening since the BouncyCastle version turned out to be annoying.

from o1c.