openssl
openssl copied to clipboard
fips: make PKCS #1 v1.5 padding bannable
The end of 2023 transitions ban PKCS #1 version 1.5 padding from the FIPS provider. This adds an option to the FIPS provider that disallows access to swich padding. At this stage, the option is not enabled by default but can be.
- [x] documentation is added or updated
- [x] tests are added or updated
I wonder how well libssl copes if this option is set? I guess it will still send pkcs1.5 based sigalgs. I suppose TLSv1.3 should mostly be ok, but I wonder how many existing cert chains use this padding....
...is the padding banned for both sign/encrypt and verify/decrypt?
If enabled, it is banned for all (although there are likely paths through the code that could access it). Hence, it's not on by default & probably won't ever be.
I wonder whether it is worth having an option to ban it only for sign/encrypt. I imagine it will be some while before all cert chains have eradicated PKCS1.5 sigs.
NIST's transition is for all use not just some. Allowing a partial or total block might be interesting.
NIST's transition is for all use not just some.
I would be totally un-suprised if they change that stance.
Allowing a partial or total block might be interesting.
I could see a partial block as being far more useful in the short to medium term than a total block. But it wouldn't hurt to have both.
@t8m pointed out is not the signatures. Thankfully.
You may be interested in what was done in Red Hat patches for this purpose
Exempted sign/verify from the padding restriction. Hardened the encrypt/decrypt paths and not checked during initialisation.
I have tested the option. It work goodly. Tests are rather unhappy it but I'm not fixing the tests at this point.
So testing it is trivial. Making the tests pass while testing it isn't.
Merge commit??
No idea how I came up with one of those. Will remove when I'm back to this.
Closing this as not relevant.
I'm seeing conflicting information from the CMVP regarding the need to block use during encrypt/decrypt. Any background on why you backed off this change ?
Thanks
The transition is still a while away. We're doing it later, likely using a different more general approach.
Do we want to revive this?