The idea is to extend the limited 12 byte AES-GCM nonce with a 32 byte info
(randomly generated per write) that is fed into HKDF-Expand (the secret
is the "DEK seed" and the hash
is SHA-256). We read 32 bytes from HKDF-Expand to use as the AES-GCM DEK.
We want the crypto properties of KMS v1 (one DEK per write) without the network overhead. The DEK seed (32 random bytes) is generated on server start up and automatically rotated whenever the remote KEK changes. Note that the HKDF-Extract step is skipped because we already have a good pseudo random key (thus there is no salt
, only info
).
This allows us to return to a purely per-write random 12 byte nonce for AES-GCM because each generated DEK+nonce combination is unique (the chance of collision is negligible). VM state restores will no longer be an issue.
While not strictly necessary, a cache will be used to memoize the HKDF operations as they are fully deterministic based on the inputs. This significantly reduces the overhead of the key generation both in terms of CPU time and memory allocations.
Note that the info
must be stored (in the clear) with the ciphertext, meaning we increase the storage overhead by 32 bytes.