Yes, it would be cool, especially if it’s feature-gated. I’m not sure what you’re talking about in the second one, this sounds sensitive enough to not be able to give an opinion without seeing the code first. I don’t remember what SealingKey and OpeningKey are, tbh.
I’m ashamed to say I couldn’t get pijul
to work on my macOS, so here’s a diff: https://github.com/Eugeny/thrussh/compare/aes256gcm?expand=1
Here are the main points:
&mut self
, this method could instead be an inc_nonce()
)Cipher
field to indicate the nonce size: https://github.com/Eugeny/thrussh/compare/aes256gcm?expand=1#diff-d1aa420cf887c9827473fe6bf0a4701dec0288a2191cd9dcc7b1641039d1c6d3R27 (make_*_cipher
methods now take a nonce
argument)Let me know if you see anything that needs changing!
Hi, I know you said you’d like to concentrate on supporting modern ciphers only, but are you open to accepting an AES256-GCM implementation into the repo?
I have one ready to go (via
thrussh-libsodium
).If you’re up to it - GCM needs an internal counter, and it can’t use the sequence number directly since the first two packets are not encrypted. Is making SealingKey and OpeningKey trait methods take a mutable
self
an acceptable solution, or is it ok to just hardcode the GCM counter assequence_number - 3
like I did?