W3C home > Mailing lists > Public > public-webcrypto@w3.org > February 2013

Re: Making choices for developers (Re: Incomplete blocks)

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 14 Feb 2013 16:09:59 -0800
Message-ID: <CACvaWvZ6Gq6i7B8KVuZA=XNt21AwNbtt6aU-FxfQ+rxxxa4NsQ@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
On Thu, Feb 14, 2013 at 3:45 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> [Changed the subject, since we seem to be veering off]
>
> On Feb 14, 2013, at 3:24 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Thu, Feb 14, 2013 at 12:18 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Ok, great.  Thanks, that does clarify things.  I had missed the padding spec in the CBC section.
>>>
>>> However, it seems rather outside the spirit of the low-level API to include padding in the algorithm.  It's necessary in some cases (e.g., RSA signature schemes), but for CBC, it could just as easily be done by the application.
>>>
>>> --Richard
>>
>> Having reviewed multiple implementations for the Lucky 13 fix (not to
>> mention code that attempts to address Bleichenbacher's attack,
>> Manger's attack, etc), I strongly disagree here. The past three
>> decades of crypto has shown us that the padding is as intrinsic to the
>> security properties as the other 'secret' data. For that reason, the
>> argument is that the padding should be handled within the API (and
>> properly, and securely), rather than foisting that on the higher
>> layer.
>>
>> This also reflects every major cryptographic API, for the same reasons.
>>
>> The spirit of the low-level API is to try to place the boundaries at
>> secrets, particularly on areas involved with secret-dependent loads or
>> secret-dependent branches, while at the same time trying to provide a
>> usable set of primitives for a variety of applications. I readily
>> acknowledge that the only "true" way to fully hide all
>> secret-dependent loads/branches is to provide a hyper-dumbed down
>> high-level API that provides the caller no flexibility (at the
>> /potential/ gain of security), so this is an attempt to provide a
>> functionally usable balance.
>
>
> This is starting to remind me of the discussion we had a little while back about IVs.
>
> For both IVs and padding algorithms, there are choices that are generally good and bad, and the reasons are pretty subtle.  For IVs the risk of bad choices seems even larger than for padding, in terms of both likelihood and impact.  It is not hard to image some lazy or non-crypto-initiate developer saying "What's this IV thing?" and just setting it to a constant value.

So, while I understand where you're coming from, I think you're
suggesting things as related when they are in fact not.

Can you implement 'safe' padding checks - whether RSA or CBC+PKCS#5 -
purely in JS? The answer: No. Constant timing will doom you.

Can you implement 'safe' IV generation? Yes - getRandomValues (or,
depending on your protocol, your IV may be sourced from some external
variable - such as a message counter/block counter)

Can you implement 'safe' tag lengths? Yes. You're specifying a tag
length. Nothing special here.

So while I understand your position, I fear you've missed the argument
I was making.

Ultimately, the merits of your suggestion seem to boil down to:
1) Consistency - which I addressed above, restating the reasoning
provided before. This is, admittedly, a 'taste' thing, ergo one that
can be bikeshedded (bikeshod?) to death.

2) "Friendlier" for non-crypto developers - which I would argue is
inherently not a property of *any* cryptographic algorithm, and can be
reasonably shown through work like
http://cr.yp.to/highspeed/coolnacl-20120725.pdf

Beyond the many reasons that have been repeatedly given for why
defaults do not make sense (which you have failed to address in past,
and which are not addressed here), I would again suggest that the
defaults being proposed neither lead to better code (either from
security or from idiomatic practices) nor do they help developers -
but rather, hinder them.

>
> Pretty much all of the security parameters have similar problems.  ("What's this tag length thing?  I'll just set it to 0.")  We should pick a strategy here and stick to it.
>
> ISTM that the right answer in basically all cases is to provide a sensible default (PKCS7 padding, unique random IVs, full length tags), but allow the developer to specify if they think they know better.  Allow them to specify an IV or tag length; allow them to turn off padding (and throw and exception when there's not a whole block); but do the smart thing unless the developer says otherwise.
>
> --Richard
>
>
>
Received on Friday, 15 February 2013 00:10:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 February 2013 00:10:34 GMT