-
Notifications
You must be signed in to change notification settings - Fork 18.3k
crypto/internal/boring: make dst allocation for AES-GCM more efficient #74740
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: master
Are you sure you want to change the base?
Conversation
When the Seal or the Open function for AES-GCM is called with a dst of insufficient size, the implementation currently call the append function in a loop until dst has enough capacity. This results in many unnecessary allocations and copy operations. For example, if we call: aeadCipher.Seal(nil, nonce, plaintext, associatedData) for a plaintext of size 1MB, we will currently make 33 allocations. After this change, we only make one allocation.
This PR (HEAD: c3411e1) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/go/+/690155. Important tips:
|
Message from Gopher Robot: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Gopher Robot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 1: (3 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
This is simpler and also more efficient when seal or open are called many times in sequence.
This PR (HEAD: 91b37d7) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/go/+/690155. Important tips:
|
This PR (HEAD: 4af65de) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/go/+/690155. Important tips:
|
Message from Juerg Wullschleger: Patch Set 3: (3 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 3: Auto-Submit+1 Code-Review+2 Commit-Queue+1 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Go LUCI: Patch Set 3: Dry run: CV is trying the patch. Bot data: {"action":"start","triggered_at":"2025-07-25T15:51:57Z","revision":"c8c3ab867ffb592a234971c935bfdcef33757ded"} Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 3: -Commit-Queue Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Go LUCI: Patch Set 3: This CL has failed the run. Reason: Tryjob golang/try/gotip-linux-arm64-boringcrypto has failed with summary (view all results):
To reproduce, try Additional links for debugging:
Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Go LUCI: Patch Set 3: LUCI-TryBot-Result-1 Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 3: -Auto-Submit -Code-Review Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 3: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Roland Shoemaker: Patch Set 3: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
Message from Jorropo: Patch Set 3: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/690155. |
When the Seal or the Open function for AES-GCM are called with a dst of
insufficient size, the implementation currently calls the append function
in a loop until dst has enough capacity. This results in many unnecessary
allocations and copy operations.
For example, in this call with a a plaintext of size 1MB:
aeadCipher.Seal(nil, nonce, plaintext, associatedData)
we will currently make 33 allocations.
After this change, we only make one allocation.