Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5

From: Hanno Böck <[email-masked]>
Date: Mon, 1 Mar 2021 11:16:39 +0100

On Sun, 28 Feb 2021 19:47:15 +0000
Stephen Farrell <[email-masked]> wrote:

> On 28/02/2021 19:26, brian m. carlson wrote:
> > 
> > I think it's very clear, based on a history of CVEs, that as
> > practically implemented, PKCS #1 padding is weak compared to PSS
> > and OAEP.  
> 
> FWIW, my impression is that that is not clear. Quite a few
> people do have that position for sure, but equally, the views
> expressed by e.g. Werner and Peter Gutmann also seem fairly
> commonly held afaics.

I saw Peter Gutmann's notes on PSS a while ago [1] and was considering
writing a reply, but I didn't find the motivation and was unsure how
relevant this is given the demise of RSA.

I wrote my thesis on PSS, so I'm quite familiar with it. I think
Gutmann has some points, but these are almost entirely not really
weaknesses in PSS itself, but of an amount of excess flexibility in the
standard that could easily be fixed.

I believe there are basically 2 changes that would make PSS much less
fragile. I know OAEP less, but I think it's pretty much the same
situation:

a) There's an excess of parameter choices for PSS. It allows choosing
2 different hash functions, a mask generation function (which has only
one choice available) and a salt length. If you remove that flexibility
(by simply defining "use sha256, use the standard mgf1 as there is no
other one, use the default salt length of 20, don't support anything
else") all issues with it go away.

b) There's a lot of cornercases in the algorithm due to the fact that
the standard allows a completely flexible key size. If you'd say "only
key sizes that are a multiple of 8" (or even "only 2048/4096 bits are
allowed") the implementation gets much simpler and is pretty
straightforward.

One could easily define RSA-PSS-Simple (or RSA-OAEP-Simple) with these
two restrictions and I believe that would remove most concerns about
complexity. Though given that the world is moving away from RSA and the
big postquantum revolution is coming anyway I'm not sure it's worth
doing that.

[1]
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html

-- 
Hanno Böck
https://hboeck.de/

---

From: Werner Koch <[email-masked]>
Date: Mon, 01 Mar 2021 13:03:58 +0100

On Sun, 28 Feb 2021 20:05, brian m. carlson said:

> Sure, I'm happy to defer this for the moment.  We don't need to make a
> decision immediately, and considering that I just proposed this

Because Brian agreed to the chair's suggestion to defer this issue, I
did not reply and I wish other don't do either.  Thanks.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 1 Mar 2021 13:29:05 +0000

brian m. carlson <[email-masked]> writes:

>Most cryptographic libraries already support RSA-PSS and RSA-OAEP, so there's
>little code to add.

*Some* crypto libraries support OAEP and PSS, but they're virtually never
used.  When they are used, they often only support the single parameter set
that whoever decided to use PSS instead of PKCS #1 went for, and fail
mysteriously if you modify any one of the 8,000 parameters that PSS and OAEP
can work with.  Admittedly this is a miniscule sample size because virtually
nothing uses them, but from the few times I've run into them it's been an
interop nightmare trying to guess what the other side will do.  The best
approach seems to be to request sample messages from the other side and then
use exactly that parameter set and nothing else for anything you send them.

Although this would tend to suggest an approach of fixing all parameters at a
given set of values, all this is then doing is reinventing an incredibly
complex equivalent to PKCS #1, which seems excessive when a much simpler
solution is to say "use encode-then-memcmp() to verify the signature" in the
spec.

Peter.