DataProtection: Move away from soon to be obsolete APIs #32511
Conversation
ghost
added
the
HaoK
changed the title
| } | ||
|
|
||
| return factory ?? Aes.Create; | ||
| return Aes.Create; |
There was a problem hiding this comment.
Is the FIPS compliance statement no longer valid?
There was a problem hiding this comment.
AesCryptoServiceProvider is being obsoleted, not sure if the base API is FIPS compliant?
There was a problem hiding this comment.
Yup, but that's in netcore, no? Aes in net461 is probably not FIPs compliant. Do we need to cross-compile this?
There was a problem hiding this comment.
@GrabYourPitchforks is this safe to just always use Aes.Create now?
There was a problem hiding this comment.
LGTM! Keep in mind that since you're cross-compiling for downlevel, if you need to change how hash algorithm factories work, you'll want to ifdef core vs. full framework so that you call the correct overload to maintain FIPS compliance.
For encryption algorithms like AES / 3DES, your PR doesn't affect FIPS compliance, so things look good.
I'm not sure I understand the issue here, but I'm assuming you are talking about possible future changes only? |
Correct. I mean that on Full Framework and netstandard, you should continue to prefer things like For AES and 3DES (the algorithms touched as part of this PR), this isn't a concern. I just wanted to alert you to something that you might have to consider in a future PR. |
|
@dougbu With this merged, is ASP.NET now clear for dotnet/runtime#52303 to be merged? |
|
Hi @jeffhandley. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
|
Worst that will happen is the dependency PR needs a bit more work @jeffhandley 😀 |
Preparation for runtime obsoleting these APIs in an incoming runtime PR