Re: PKCS#1v1.5

Right, I can see how that could get out of hand rather quickly.  The difference I see between those cases though is that counter mode and CBC each have advantages/disadvantages (i.e. counter mode allows for random access to encrypted data) that warrant using one over the other depending on the scenario.  Hopefully developers will investigate the different modes before they pick the one that most suits their situation.  PKCS#1 and OAEP on the other hand are functionally equivalent, but one has potential security holes and the other does not.  


On Wednesday, September 19, 2012 at 2:22 PM, Ryan Sleevi wrote:

> On Wed, Sep 19, 2012 at 11:00 AM, Travis Mayberry <travism@ccs.neu.edu (mailto:travism@ccs.neu.edu)> wrote:
> > 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.
> > 
> 
> 
> Yes, that is a concern a number of us in the WG have expressed. At the
> same time, in seeking to provide a low-level API, it is inherent that
> we end up providing more than enough rope to hang oneself, and are
> definitely leaving a few loaded guns on the table. So far, our hope
> has been that developers will be able to take these primitives, and
> combine them into the appropriate secure protocols and interfaces (for
> example, the IETF's JOSE work). To support a variety of protocols, we
> provide the low-level APIs, but for individual applications, they
> likely only need to support a particular protocol or construct.
> 
> That said, adding a note seems to make sense. We'll just need to
> balance it with trying to keep the spec focused on the API itself,
> rather than trying to re-iterate all of the security considerations
> for all of the algorithms. For example, should AES-CTR or AES-CBC
> warrant a note that they lack integrity protection? Should they
> warrant notes about the importance of performing the integrity
> protection over the ciphertext (*and* IV), rather than the plaintext?
> With crypto, the number of security considerations can quickly spiral
> out of control.
> 
>