-
Notifications
You must be signed in to change notification settings - Fork 18
feat: add AES protected key interface and implementation #2599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: add AES protected key interface and implementation #2599
Conversation
Add ProtectedKey and Encapsulator interfaces to lib/ocrypto package, along with AESProtectedKey implementation. This exposes previously internal cryptographic functionality for external consumption. - Add interfaces.go with ProtectedKey and Encapsulator interfaces - Add protected_key.go with AESProtectedKey implementation - Add comprehensive test suite in protected_key_test.go - Use standard error types without logging dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @strantalis, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request aims to expose and standardize key management operations within the lib/ocrypto
package by introducing new interfaces and a concrete AES-based implementation. This change modularizes cryptographic functionality, allowing for broader and more consistent consumption of protected keys across the system.
Highlights
- New Interfaces: I've introduced
ProtectedKey
andEncapsulator
interfaces inlib/ocrypto/interfaces.go
. These interfaces define standard operations for managing and encapsulating cryptographic keys, making previously internal functionality accessible. - AESProtectedKey Implementation: A concrete implementation,
AESProtectedKey
, has been added inlib/ocrypto/protected_key.go
. This struct implements theProtectedKey
interface, providing methods for AES-GCM decryption, secure key export (with optional encapsulation), and policy binding verification using HMAC-SHA256. - Comprehensive Testing: I've included a thorough test suite in
lib/ocrypto/protected_key_test.go
. These tests cover theAESProtectedKey
's core functionalities, various error conditions, and ensure its compliance with theProtectedKey
interface, including the use of a mock encapsulator for isolated testing.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
New crypto flows, Keys protected, safe and sound, Code now open wide.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a new ProtectedKey
interface and its AESProtectedKey
implementation for cryptographic operations. The changes are well-structured and include a comprehensive test suite.
My review focuses on improving security and code clarity. Key suggestions include:
- Preventing slice aliasing in the constructor and
Export
method to enhance security by copying the key data. - Refactoring
generateHMACDigest
to remove an unused context parameter and a redundant error check.
- Add defensive copying in constructor to prevent external mutation - Add defensive copying in Export method for security - Simplify generateHMACDigest by removing unused context and error handling - Update tests to match simplified signature Addresses feedback from code review on PR opentdf#2599
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces new interfaces for cryptographic operations and an AESProtectedKey
implementation. The code is well-structured and includes a comprehensive test suite. The review focuses on improving performance by suggesting to initialize the AES cipher once in the constructor and to correct the AES key sizes in the tests.
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces new interfaces (Encapsulator
, ProtectedKey
) and an implementation (AESProtectedKey
) for cryptographic operations, exposing them for external use. The changes are well-structured and include a comprehensive test suite.
My review focuses on improving API clarity, consistency, and addressing potential security risks. Key points include:
- Refining the new interfaces for better naming and documentation, following Go conventions.
- Highlighting two significant security considerations in
AESProtectedKey
: the storage of raw keys in memory and the ability to export them unencrypted. These create potential "footgun" scenarios that could lead to accidental key exposure. - Suggesting improvements to the test suite for better maintainability and to test against the public API rather than internal state.
Overall, the PR is a good addition, but the security implications should be carefully considered and addressed.
type AESProtectedKey struct { | ||
rawKey []byte | ||
aesGcm AesGcm | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Storing the raw cryptographic key in a []byte
field poses a security risk. The key will reside in plaintext in the application's memory, making it potentially vulnerable to memory-dumping attacks or other memory inspection vulnerabilities (e.g., side-channel attacks like Spectre/Meltdown).
While this may be an intentional design choice for performance, it's a significant security trade-off. For a library providing cryptographic primitives, it's crucial to be explicit about these risks.
Consider adding a prominent warning in the documentation for AESProtectedKey
and NewAESProtectedKey
about this behavior and the risks involved.
func (k *AESProtectedKey) Export(encapsulator Encapsulator) ([]byte, error) { | ||
if encapsulator == nil { | ||
// Return raw key data without encryption - caller should be aware of this | ||
return append([]byte{}, k.rawKey...), nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allowing a nil
encapsulator in the Export
method, which then returns the raw, unencrypted key, creates a potential security vulnerability. It's easy for a developer to misuse this and accidentally expose the key. This is often referred to as a "footgun" API.
To make the API safer, I'd recommend disallowing a nil
encapsulator. If the caller needs the raw key, they should be explicit about it, perhaps through a separate, clearly named method like Raw() []byte
. This would make the intention much clearer and reduce the risk of accidental exposure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove this version? My suggestion for exporting the key is either to pass in a 'no-op' encapsulator, or add an explicit Raw() method, requiring a down-cast to AESProtectedKey
to use
protectedKey, err := NewAESProtectedKey(key) | ||
require.NoError(t, err) | ||
assert.NotNil(t, protectedKey) | ||
assert.Equal(t, key, protectedKey.rawKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accessing the unexported field rawKey
makes this test brittle to implementation changes. It's better to test the public behavior of the object. You can use Export(nil)
to get the key and verify it's equal to the original key. This tests the public API rather than internal state.
exported, err := protectedKey.Export(nil)
require.NoError(t, err)
assert.Equal(t, key, exported)
|
||
// Encapsulator interface for key encapsulation operations | ||
type Encapsulator interface { | ||
// Encrypt wraps a secret key with the encapsulation key |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow we don't have an Encapsulate
// Encrypt wraps a secret key with the encapsulation key | |
// Encapsulate wraps a secret key with the encapsulation key | |
Encapsulate(dek ProtectedKey) ([]byte, error) | |
// Encrypt encrypts extra data with the encapsulation key |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmihalcik-virtru Do we have a use for this today? I can add it and just leave it unimplemented for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather expose just Encapsulate than Encrypt if I had to choose
// For EC schemes, this method returns the public part of the ephemeral key. | ||
// Otherwise, it returns nil. | ||
EphemeralKey() []byte |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be replaced by an additional return value from encapsulate/encrypt perhaps? I really think we need to move the ek into the body of the wrappedKey array, since ML-KEM will generate a different value for each encapsulate operation IIRC. It is confusing that right now this and the PEM export method have the same implementation for EC operations, as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can leave this for now then remove / update in a future version of ocrypto
func (k *AESProtectedKey) Export(encapsulator Encapsulator) ([]byte, error) { | ||
if encapsulator == nil { | ||
// Return raw key data without encryption - caller should be aware of this | ||
return append([]byte{}, k.rawKey...), nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove this version? My suggestion for exporting the key is either to pass in a 'no-op' encapsulator, or add an explicit Raw() method, requiring a down-cast to AESProtectedKey
to use
Proposed Changes
Add ProtectedKey and Encapsulator interfaces to lib/ocrypto package, along with AESProtectedKey implementation. This exposes previously internal cryptographic functionality for external consumption.
Checklist
Testing Instructions