Re: PKCS#1v1.5

On Wed, Sep 19, 2012 at 11:00 AM, Travis Mayberry <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.

Received on Wednesday, 19 September 2012 18:22:27 UTC