openssl icon indicating copy to clipboard operation
openssl copied to clipboard

fips: make PKCS #1 v1.5 padding bannable

Open paulidale opened this issue 2 years ago • 11 comments

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

paulidale avatar Nov 14 '22 01:11 paulidale

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?

mattcaswell avatar Nov 14 '22 10:11 mattcaswell

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.

paulidale avatar Nov 14 '22 10:11 paulidale

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.

mattcaswell avatar Nov 14 '22 10:11 mattcaswell

NIST's transition is for all use not just some. Allowing a partial or total block might be interesting.

paulidale avatar Nov 14 '22 10:11 paulidale

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.

mattcaswell avatar Nov 14 '22 10:11 mattcaswell

@t8m pointed out is not the signatures. Thankfully.

paulidale avatar Nov 14 '22 11:11 paulidale

You may be interested in what was done in Red Hat patches for this purpose

beldmit avatar Nov 14 '22 11:11 beldmit

Exempted sign/verify from the padding restriction. Hardened the encrypt/decrypt paths and not checked during initialisation.

paulidale avatar Nov 14 '22 19:11 paulidale

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.

paulidale avatar Nov 14 '22 23:11 paulidale

Merge commit??

mattcaswell avatar Nov 16 '22 11:11 mattcaswell

No idea how I came up with one of those. Will remove when I'm back to this.

paulidale avatar Nov 16 '22 22:11 paulidale

Closing this as not relevant.

paulidale avatar Dec 15 '22 00:12 paulidale

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

bfussell avatar Feb 10 '23 16:02 bfussell

The transition is still a while away. We're doing it later, likely using a different more general approach.

paulidale avatar Feb 11 '23 13:02 paulidale

Do we want to revive this?

t8m avatar Aug 25 '23 13:08 t8m