Fwd: [Moderator Action] Re: On Crypto API Safety in the Hands of Unskilled Developers

-------- Original Message --------
Subject: [Moderator Action] Re: On Crypto API Safety in the Hands of
Unskilled Developers
Date: Fri, 29 Mar 2013 04:34:12 +0000
From: Trevor Perrin <trevp@trevp.net>
To: Richard Barnes <rbarnes@bbn.com>
CC: public-webcrypto@w3.org Working Group <public-webcrypto@w3.org>

Hi,

Long-time listener, first-time caller.


On Thu, Mar 28, 2013 at 8:20 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>
> The current API's approach of exposing unmitigated complexity to the developer -- no defaults, no help from the browser -- is only plausible if we assume that the only people who will use the API are experienced cryptographers.  This assumption is clearly not true.  Any API that is supplied in the DOM will be exposed to, and get used by, a much wider variety of developers than we ever intend.

The developers using this (or any) low-level crypto API don't need to
be cryptographers, but shouldn't they be implementing higher-level
protocols designed by cryptographers?

You seem to be under the assumption that if an API hides a few simple
details (like choosing IVs), secure protocol design becomes safe and
easy for everyone.

But I'm skeptical a developer who can't understand IVs has any
business messing with the more complex issues of protocol design, such
as public-key and symmetric-key semantics, rollback / replay / relay /
reflection attacks, key agreement protocols and key management,
notions of compromise resistance (forward secrecy, key-compromise
impersonation), resistance to traffic analysis and side-channels,
secure parsing, understanding security proofs and performance
tradeoffs, and so on....

As an example of these subtleties:

> Conceptually, there are two classes of CryptoOperation: "Plain to ciphertext" operations that convert plaintext to data with cryptographic structure, and "Cipher to plaintext" operations that do the reverse.
>
> P2C       C2P
> -----------------
> sign      verify
> encrypt   decrypt
> digest

Public-key signatures are *NOT* ciphertexts, and signature
verification does *NOT* convert a ciphertext to plaintext.  This is a
common confusion, but can result in horrible protocol mistakes.

[...]
> These don't prevent developers from running into problems -- choosing bad IVs, or deleting default parameters from the object -- but it encourages a default life-cycle that should be problem free:
> * Process plaintext, get ciphertext+parameters
> * Store ciphertext+parameters
> * Process ciphertext+parameters, get plaintext

This is a risky idiom: having the recipient of a message process
unauthenticated cleartext parameters means, firstly, you are leaking
some sort of information in the clear.  Secondly, by messing with the
parameters, an attacker gains substantial ability to modify the
message via rollback / reinterpretation attacks.

So in sum: there's a lot of subtleties and sharp edges to secure
protocol design.  It would be nice if some simple API tweaks would
make these go away, so "regular" developers could start whipping
together ciphers and whatnot into secure protocols.  But that's not
realistic.


Trevor

Received on Friday, 29 March 2013 18:35:48 UTC