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.

Sign up for GitHub

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

Jump to bottom

RFE - XChaCha20 support #35

Closed
cipherboy opened this issue Jan 6, 2024 · 0 comments · Fixed by #36
Closed

RFE - XChaCha20 support #35

cipherboy opened this issue Jan 6, 2024 · 0 comments · Fixed by #36

Comments

@cipherboy
Copy link
Member

cipherboy commented Jan 6, 2024 •
edited
Loading

Copied from hashicorp/vault#13243, reported by @DemiMarie:

Is your feature request related to a problem? Please describe. Currently, transit keys need to be rotated after 2³² uses, due to the algorithm employed (AES-GCM with a random nonce).

Describe the solution you'd like Use a long, random nonce with an algorithm such as XChaCha20-Poly1305. For algorithms such as AES-GCM that don’t support this natively, one can use any KDF with a root key and any random number, and include the number in the nonce.

Describe alternatives you've considered Maintain a stateful counter on each node, together with a consensus algorithm to ensure that each node has a unique node number. This is not particularly attractive, since it means a consensus problem turns into a cryptographic disaster.

Explain any additional use-cases Operations are dramatically simplified: users do not need to worry about key rotation. The overhead of the KDF should be dwarfed by the overhead of the Vault RPC itself, unless I am missing something.

Additional context Most people do not deal with key rotation (https://github.com/hashicorp/vault/issues/13025#issuecomment-961889260), nor should they need to.
cipherboy added a commit to cipherboy/openbao that referenced this issue Jan 6, 2024
@cipherboy
Add support to Transit, keysutil for XChaCha20-Poly1305
dd2957d 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: openbao#35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
@cipherboy cipherboy mentioned this issue Jan 6, 2024
Merged
cipherboy added a commit to cipherboy/openbao that referenced this issue Jan 6, 2024
@cipherboy
Add support to Transit, keysutil for XChaCha20-Poly1305
318c387 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: openbao#35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
cipherboy pushed a commit to cipherboy/openbao that referenced this issue Jan 21, 2024
@robmonte
Move testing info to its own section in the README (openbao#35)
1bd0561 
* Move testing info to its own section in the README
cipherboy pushed a commit to cipherboy/openbao that referenced this issue Jan 21, 2024
@robmonte
Update dependencies and release tag (openbao#35)
17019ff 
* Update deps

* update changelog
cipherboy added a commit to cipherboy/openbao that referenced this issue Feb 5, 2024
@cipherboy
Add support to Transit, keysutil for XChaCha20-Poly1305
b06bb72 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: openbao#35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
cipherboy added a commit to cipherboy/openbao that referenced this issue Feb 5, 2024
@cipherboy
Add support to Transit, keysutil for XChaCha20-Poly1305
e5a9490 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: openbao#35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
cipherboy added a commit to cipherboy/openbao that referenced this issue Feb 12, 2024
@cipherboy
Add support to Transit, keysutil for XChaCha20-Poly1305
66cc67b 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: openbao#35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
naphelps pushed a commit that referenced this issue Feb 12, 2024
@cipherboy @naphelps
Add support to Transit, keysutil for XChaCha20-Poly1305
a730916 
This adds support for XChaCha20-Poly1305, a variant of ChaCha20-Poly1305
with double the nonce size (12->24). Due to the construction of most AEAD
cipher modes which lack a synthetic IV (mostly this and GCM), nonce
reuse becomes problematic. A small default nonce size (96 bits) results
in only 96/2 = 2^48 message encryptions before reuse becomes likely
due to the birthday paradox. As a result, NIST has mandated 2^32 as the
upper limit on AES-GCM encryption operations in FIPS to keep the
threshold sufficiently small. This necessitates key rotation when the
limit is reached.

By using a larger nonce (24-bytes), key rotation can be avoided.

Resolves: #35

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
@cipherboy cipherboy mentioned this issue Mar 27, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add support to Transit, keysutil for XChaCha20-Poly1305 cipherboy/openbao
1 participant
@cipherboy