Re: PKCS#1v1.5

Makes sense.  I would suggest then that a note be put in emphasizing it should be used carefully and that OAEP is the better choice if you are not forced to use PKCS#1.  My main concern is that a developer, upon deciding to use this API but not being familiar with the issues we are discussing, will simply pick one of the two at random and potentially open himself up to an attack that could have easily been avoided.  

On Wednesday, September 19, 2012 at 1:36 PM, Ryan Sleevi wrote: 
> On Tue, Sep 18, 2012 at 10:27 AM, Travis Mayberry <travism@ccs.neu.edu (mailto: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).
> 
>