Making choices for developers (Re: Incomplete blocks)

[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.  

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 Thursday, 14 February 2013 23:46:06 UTC