Closed jvz closed 3 years ago
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.
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.
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.
Reopening since the BouncyCastle version turned out to be annoying.
This cipher SPI should provide basic low level functionality that follows RFC 7539 for ChaCha20-Poly1305. This should have at least two core implementations: one based on BouncyCastle, and the other based on Java 11.