Re: Incomplete blocks

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.

Received on Thursday, 14 February 2013 20:25:01 UTC