Re: PKCS#1v1.5

On Tue, Sep 18, 2012 at 10:27 AM, Travis Mayberry <travism@ccs.neu.edu> wrote:
> I am curious as to why the proposed API includes PKCS#1v1.5 as a padding
> mode for RSA.  It has been known since 1998 (due to Bleichenbacher and
> improved later) to be vulnerable to padding oracle attacks.  For some time
> it was questionable whether these attacks were useful in real world
> situations but this year at CRYPTO there was a paper where another improved
> version of the attack was used to break cryptographic tokens which relied on
> PKCS#1v1.5.  Considering this is a new API not burdened with the shackles of
> backward compatibility, why not simply go with OAEP which is provably
> secure?
>
> ~Travis Mayberry

Hi Travis,

Thanks for your comments!

While your concerns about PKCS#1 v1.5 are well-founded, I feel it's at
least necessary to point out the the attacks have largely focused on
implementation issues. That is to say, it is not the underlying
algorithm itself that is vulnerable, but that it can be made
vulnerable with an improper or ill-considered implementation. Such
attacks exist for a number of algorithms, so I do not think this is
particularly new or unique here. Such was the case of the
cryptographic tokens, which failed to implement PKCS#1 v1.5 in a
secure manner. Just as well, they could have failed to implement PSS
or OAEP in a secure manner, so I don't know if it's good to conflate
implementation bugs with underlying algorithm flaws.

As it relates to "a new API not burdened with the shackles of backward
compatability", I fear there are two layers at play here. As far as
API goes, you are correct - this is a new API, so any algorithm we
choose not to support will not 'break' any client that is using it -
since such clients don't exist. However, PKCS#1 v1.5 is still used in
a wide number of protocols and signature schemes. If you wanted to use
this API to implement those protocols, failing to include PKCS#1 v1.5
makes this impossible.

This was one area where the WG has spent a fair amount of time
discussing - should it be possible to use this API to implement
existing protocols, or should all new applications invent new
cryptographic protocols and schemes? I feel that failing to even be
able to support existing, standards based protocols would be more
detrimental to the API than supporting some of these more troubling
schemes, such as PKCS#1 v1.5 or supporting raw AES or AES in ECB mode
(for the purposes of bootstrapping other modes or other protocols).

Received on Wednesday, 19 September 2012 17:37:01 UTC