[ext]: Seal DEKs with a standard set of ciphers - #173
pseudomuto wants to merge 1 commit into
Conversation
KeyMaterial gave extension servers a framing so they stopped hand-rolling binary layouts, but it left the cryptography with them. Writing a provider still meant building an AEAD, generating a nonce, choosing additional data, and re-checking the nonce length on the way back in. Those are the parts where a mistake is silent rather than loud. Add a key wrapper that takes a lookup for wrapping keys and does the rest. It seals with an AEAD, frames the result as KeyMaterial, and opens it again. AES-256-GCM is the default, but ChaCha20-Poly1305 and XChaCha20-Poly1305 are also available. A caller can registers others via `ext.WithCipherFunc`. Where key bytes come from stays with the implementor. Owning the derivation would mean owning its migration story too (nope), so the example keeps its HKDF and loses everything else.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! 🚀 New features to boost your workflow:
|
| token, serves TLS, and shuts down on a signal. Start with `keyring.go` if you are writing one of these against a real | ||
| key service, because that method is the part you replace: |
There was a problem hiding this comment.
Could we qualify this to key services that can return the raw wrapping-key bytes? Some managed key services keep their keys non-exportable and provide only wrap and unwrap APIs. Those implementations would use KeyMaterial for the common framing but continue implementing ext.KMS directly instead of using NewKeyWrapper.
dipali-bhatt
left a comment
dipali-bhatt
left a comment
There was a problem hiding this comment.
Thanks for putting this together. For managed key services such as SF KMS, the wrapping key is non-exportable, so the extension cannot return the raw key bytes required by NewKeyWrapper.
Would you consider adding a companion helper, that defines provider-neutral wrap and unwrap callbacks and implements the surrounding ext.KMS and KeyMaterial construction and parsing? The extension callbacks would continue to own authentication, API calls, algorithm and field validation, integrity protection, error mapping, and backend-specific key semantics.
This would keep the solution provider-neutral while allowing managed-KMS integrations to avoid implementing their own durable record encoding and decoding.
4 participants
KeyMaterial gave extension servers a framing so they stopped hand-rolling binary layouts, but it left the cryptography with them. Writing a provider still meant building an AEAD, generating a nonce, choosing additional data, and re-checking the nonce length on the way back in. Those are the parts where mistakes are silent rather than loud.
Add a key wrapper that takes a lookup for wrapping keys and does the rest. It seals with an AEAD, frames the result as KeyMaterial, and opens it again. AES-256-GCM is the default, but ChaCha20-Poly1305 and XChaCha20-Poly1305 are also available. A caller can register others via
ext.WithCipherFunc.Where key bytes come from stays with the implementor. Owning the derivation would mean owning its migration story too (nope), so the example keeps its HKDF and loses everything else.