Skip to content

Transit: Support algorithms with large nonces #13243

@DemiMarie

Description

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions