hesela.devEnvelope encryption
Envelope encryption protects data with a data-encryption key and protects that key with a separate key-encryption key.
Key hierarchy: the data-encryption key (DEK) encrypts the payload; the key-encryption key (KEK) wraps the DEK. Storage retains ciphertext and a wrapped DEK, while decryption needs an authorized path to unwrap the DEK. A KEK can protect many DEKs. [1]
Wrapping protects the key's confidentiality and integrity. Wrapping the DEK alone does not authenticate payload bytes or an object identifier outside the protected input; the application must provide that binding. [3]
Architectural consequence: rewrapping the same DEK under a new KEK changes its encrypted representation, not the payload key. The existing payload ciphertext can remain unchanged. Re-encrypting the payload with a new DEK is a separate migration. [1] [4]
Recovery dependency: losing the only usable unwrapping path can make retained ciphertext unreadable. Rotation alone leaves prior versions usable in the cited key-version lifecycle; it is not evidence of cryptographic erase. [2]
Relations
Citations
- Google Cloud KMS: Envelope encryption, data keys and key-encryption keys
- Google Cloud KMS: Key rotation, after you rotate keys
- NIST SP 800-38F (2012): Methods for Key Wrapping, sections 3.1, 5.2 and Appendix B.2
- Google Cloud KMS: Re-encrypting data, workflow
Sources & caveats
- Google Cloud KMS supplies the example hierarchy and key-version lifecycle; these are not guarantees about every storage device.
- NIST SP 800-38F is used for wrapping semantics, not to recommend every legacy algorithm in its 2012 edition.