search

hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
30.02k stars 4.12k forks source link

Transit: Support algorithms with large nonces #13243

Open DemiMarie opened 2 years ago

DemiMarie commented 2 years ago

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, nor should they need to.

hsimon-hashicorp commented 2 years ago

Thanks for this request, @DemiMarie! I'll have our engineers take a look at it. There might be a slight delay, due to the holiday week etc, but rest assured we won't forget about it. Thanks again! :)

DemiMarie commented 2 years ago

You’re welcome @hsimon-hashicorp!

stevendpclark commented 2 years ago

Thank you @DemiMarie for the proposal!

We have discussed it internally and while we are not opposed to your proposed solution, it would be a rather large change to undertake. We would need additional thought and planning around implementation and customer upgrade paths.

We would like to investigate another possibility that is better aligned with the industry usage of AES-SIV. At this time these are just internal investigations. No decisions have been made but we will consider this for future releases.

Additionally, as you mentioned, performance hits for single encryption operations shouldn't be too large but we do have some concerns for large batch operations within transit with your proposal or even with AES-SIV based solutions.

DemiMarie commented 2 years ago

@stevendpclark FYI, XChaCha20-Poly1305 is pretty fast in practice, IIRC.

victorr commented 2 years ago

Hello @DemiMarie, I just want to mention that 1.10 has just introduced a time-based key autorotation feature (#13691) which you may find useful.

DemiMarie commented 2 years ago

Hello @DemiMarie, I just want to mention that 1.10 has just introduced a time-based key autorotation feature (#13691) which you may find useful.

That is definitely useful, but it doesn’t solve the problem outright, especially since old encrypted data will no longer be accessible. This may be useful sometimes, but isn’t always acceptable.

victorr commented 2 years ago

That is definitely useful, but it doesn’t solve the problem outright, especially since old encrypted data will no longer be accessible. This may be useful sometimes, but isn’t always acceptable.

As long as the min_decryption_version is not updated, it will continue to be possible to decrypt old data.