-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Add encryption to diskqueue #31961
Add encryption to diskqueue #31961
Conversation
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
8026f5e
to
8e5d606
Compare
Benchmarks for this implementation:
Compared to the previous implementation: #31949
This version seems almost twice as fast ad allocates slightly less. What do you think caused this @leehinman? I want to make sure the improvement isn't a mirage :) |
|
|
||
func (er *EncryptionReader) Read(buf []byte) (int, error) { | ||
if cap(er.ciphertext) >= len(buf) { | ||
er.ciphertext = er.ciphertext[:len(buf)] |
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.
Are there any security concerns with the re-slicing here? Part of the previous ciphertext will potentially hang around at the end of the underlying array.
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.
No, having ciphertext around is acceptable. We expect Malory to be able to "see" cipher text. Also I would assume anyone that could view memory of the process could also view the segment file which would have the cipher text as well.
@@ -134,15 +135,26 @@ type segmentHeader struct { | |||
// If the segment file has not been completely written, this field is zero. | |||
// Only present in schema version >= 1. | |||
frameCount uint32 | |||
|
|||
// options holds flags to enable features, for example encryption. | |||
options uint8 |
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.
Any reason not to just make this larger for more future proofing? Probably nobody will notice 1-3 extra bytes in each segment file depending on uint16 or uint32 as the larger size.
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 waffled on this. In the end I picked uint8 because I couldn't think of even 8 options, but we could easily go with uint32, that would match version & count.
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.
switched to uint32
So this is because #31935 wasn't merged when the benchmark was run for #39149, that is what accounts for the speed up and drop in allocations. One thing that is directly comparable between #31935 and this PR is "1M_10k-16 21.7s ± 0%" is the same test as "Async1M-16 22.0s ± 1%" in this PR. The times are close enough that I would say the changes in this PR that add the options field, and switches to a segmentReader instead of direct io.File, don't change the speed significantly. The allocations are the same between the two. |
Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
Short term, I added comment to header of |
e7e45c6
to
3d28c63
Compare
@@ -15,8 +15,18 @@ | |||
// specific language governing permissions and limitations | |||
// under the License. | |||
|
|||
// example: go test -bench=. -benchtime 3x -timeout 60m | |||
// Usage: |
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.
👍
} | ||
dir, err := os.MkdirTemp("", t.Name()) | ||
assert.Nil(t, err) | ||
// defer os.RemoveAll(dir) |
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.
Was this supposed to stay?
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.
LGTM, wait for @faec to review before merging.
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.
looks good, thanks!
* Add encryption to diskqueue Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
What does this PR do?
Adds support for AES 128 CTR encryption to disk queue.
Why is it important?
Necessary for endpoint running under elastic-agent
Checklist
- [ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Related issues