Skip to content

Remove plaintext receive buffer#1788

Draft
Rob-Hague wants to merge 2 commits intosshnet:developfrom
Rob-Hague:decryptinplace
Draft

Remove plaintext receive buffer#1788
Rob-Hague wants to merge 2 commits intosshnet:developfrom
Rob-Hague:decryptinplace

Conversation

@Rob-Hague
Copy link
Copy Markdown
Collaborator

#1752 added a persistent buffer into which to decrypt packets, rather than allocating a new array for each packet. This was on the back of #1733 which added support in the cipher types for decrypting into a given buffer, but for the case of AES-CTR, not into the same buffer in-place. #1787 adds that missing support, meaning we can now decrypt in-place, and the plaintext buffer becomes unnecessary.

Branch based on #1787, this change is the 2nd commit

Support in-place encryption in the cipher types, then use it on the plaintext packets
instead of allocating a new array each time. Removes 2 of 4 bytes allocated for each
byte uploaded over SFTP.

For AES-CTR, supporting in-place encryption in this case means adding a persistent buffer
for the keystream and encrypting in chunks. The performance difference is ~1-2% i.e.
marginal versus one-shotting it. The variance is similar also for different choices of
buffer size (here 4096 is used).
sshnet#1752 added a persistent buffer into which to decrypt packets, rather than allocating
a new array for each packet. This was on the back of sshnet#1733 which added support in the
cipher types for decrypting into a given buffer, but for the case of AES-CTR, not into
the same buffer in-place. sshnet#1787 adds that missing support, meaning we can now decrypt
in-place, and the plaintext buffer becomes unnecessary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant