Fix over-zeroing of destination buffer for zero padding symmetric encryption #52465
Conversation
This addresses two issues with how zero padding is handled. The first is performance. When applying zero padding, we were clearing the entire destination, then copying the plaintext over it. We were zeroing more data than required, the only data that needed to be zeroed is where the zero padding is applied. The second is in the case of overlapping buffers for the plaintext and ciphertext. However, this cannot happen currently since we always ensure the destination buffer does not overlap the input buffer. If overlapping is permitted in a future change, this would clear the plaintext, not just where padding is required.
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks Issue DetailsThis addresses one issue with how zero padding is handled and another theoretical one. The first is performance. When applying zero padding, we were clearing the entire destination, then copying the plaintext over it. We were zeroing more data than required, the only data that needed to be zeroed is where the zero padding is applied. The second is in the case of overlapping buffers for the plaintext and ciphertext. However, this cannot happen currently since we always ensure the destination buffer does not overlap the input buffer. If overlapping is permitted in a future change, this would clear the plaintext, not just where padding is required. Contributes to #2406 I'm submitting this separately from the upcoming one-shot PR since that PR is getting fairly large and this is not immediately related to the one-shot APIs, but is adjacent.
|
|
Just to be clear: nothing is "broken" right now. As-is, this is a performance improvement. But it will be more important for the one-shot APIs. |
ghost
locked as resolved and limited conversation to collaborators
4 participants
This addresses one issue with how zero padding is handled and another theoretical one.
The first is performance. When applying zero padding, we were clearing the entire destination, then copying the plaintext over it. We were zeroing more data than required, the only data that needed to be zeroed is where the zero padding is applied.
The second is in the case of overlapping buffers for the plaintext and ciphertext. However, this cannot happen currently since we always ensure the destination buffer does not overlap the input buffer. If overlapping is permitted in a future change, this would clear the plaintext, not just where padding is required.
Contributes to #2406
I'm submitting this separately from the upcoming one-shot PR since that PR is getting fairly large and this is not immediately related to the one-shot APIs, but is adjacent.