Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an AEAD cipher SPI for ChaCha20-Poly1305 #1

Closed
jvz opened this issue Nov 21, 2020 · 4 comments
Closed

Create an AEAD cipher SPI for ChaCha20-Poly1305 #1

jvz opened this issue Nov 21, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@jvz
Copy link
Contributor

jvz commented Nov 21, 2020

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.

@jvz jvz added the enhancement New feature or request label Nov 21, 2020
@jvz jvz added this to the 1.0 milestone Nov 21, 2020
@jvz jvz self-assigned this Nov 21, 2020
jvz added a commit that referenced this issue Nov 23, 2020
This forms a stable starting point for #1, #2, and #3 SPIs along with providers for #8, #9, and #10. These consist of an AEAD cipher SPI, a key exchange SPI, and a signature SPI, along with providers based on BouncyCastle, Java 11, and Java 15 respectively. A small number of smoke tests are included from the relevant RFCs.
@jvz
Copy link
Contributor Author

jvz commented Nov 28, 2020

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.

@jvz
Copy link
Contributor Author

jvz commented Dec 6, 2020

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.

jvz added a commit that referenced this issue Dec 7, 2020
This implementation aims to be compatible with libsodium ristretto255 signcryption and XChaCha20-Poly1305. This relates to #5 with an enhanced implementation of #1.
@jvz
Copy link
Contributor Author

jvz commented Dec 7, 2020

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.

@jvz jvz closed this as completed Dec 7, 2020
@jvz
Copy link
Contributor Author

jvz commented Feb 27, 2021

Reopening since the BouncyCastle version turned out to be annoying.

@jvz jvz reopened this Feb 27, 2021
@jvz jvz closed this as completed in 222f76f Mar 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant