-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Pass IV through cipher resets for OpenSSL and Android #64641
Conversation
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsThe This wasn't a problem because we've always considered the Key and IV a tuple that belong together. The In order to facilitate re-usable lite cipher instances with different IVs, all platforms need to support resetting with a different IV than when it was originally constructed. This also simplifies the reset on OpenSSL since the managed side always supplies the IV, and removes a workaround from OpenSSL 3.
|
I ran the Android tests locally and everything passed, I'm uncertain if CI is covering Android right now, but I suspect not. |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
Guessing it didn't run because I merged / pushed when GitHub was unavailable yesterday. |
Since everything else passed, and this change doesn't affect OSX anyways, merging. |
The
Reset
method accepted an IV, but for OpenSSL and Android, the IV was discarded. Instead, the IV that was originally used to create the cipher context was used.This wasn't a problem because we've always considered the Key and IV a tuple that belong together. The
Lite
ciphers are meant to decouple the key from the IV, so the cipher instance can be re-used with different IVs.In order to facilitate re-usable lite cipher instances with different IVs, all platforms need to support resetting with a different IV than when it was originally constructed.
This also simplifies the reset on OpenSSL since the managed side always supplies the IV, and removes a workaround from OpenSSL 3.