Re: [W3C Web Crypto WG] Deciding the algorithms supported by the API

The list of algorithms in your message, Virginie, looks like a good
selection of algorithms to me. It provides message authentication,
digital signature, public key encryption, and authenticated
encryption.

I'm going to suggest a subset of that set, below.

I don't yet understand what the use cases are, though, and I suspect
that we can't define a set of high-level algorithms that can satisfy
most of the needs of our ultimate users. Therefore, I think we'll have
to provide a low-level API if we want to facilitate those unknown,
future uses. (Which I do.)

For example, if we standardize an AES block encryption function then
programmers could implement their own modes of AES encryption such as
CTR or OCB mode.

But leaving aside that question for the moment, what set of algorithms
should we offer in the high-level API discussed here? One answer to
that could be that we need to offer algorithm X or Y in order to allow
interop with other systems or in order to allow compliance with other
standards or regulations. There are so many! There are a lot of
possible other systems, many standards and regs, that some future user
might need to accomodate. If we're going to try to help them with
that, we should start developing a catalog. But it will be huge. I
don't think it is a good approach to provide everything in the catalog
-- instead I think we should provide the low-level API, which people
can then use to implement the specific algorithms that they have to.

But I'll leave aside that question for now too.

Having punted on the two hard questions, I'll now turn to a nice and
easy question: what is a set of good high-level algorithms?

I think the list in your strawman has some redundant alternatives in
it. Here's my even slimmer strawman in which I omit all of the
suggestions that I think are redundant.

> For signing/MAC:
>    | HS256              | HMAC using SHA-256 hash algorithm            |
>    | ES256              | ECDSA using P-256 curve and SHA-256 hash     |

> For key encryption:
>
>    | ECDH-ES   | Elliptic Curve Diffie-Hellman Ephemeral Static

> For block encryption:
>
>    | A128GCM   | Advanced Encryption Standard (AES) using 128 bit keys |
>
>    |           | in Galois/Counter Mode

The only redundancy remaining is the presence of both elliptic-curve
and non-elliptic-curve digital signatures and public key encryption,
which I include only because of the notion I've been hearing that some
people may have difficulty implementing elliptic-curve.

This minimal set of algorithms should satisfy any use case whose
requirements are simply "I need a secure digital signature algorithm
-- any secure digital signature algorithm!" and so on. It won't
satisfy use cases in which the algorithm to be used is externally
imposed, such as by interop, standards, regs, etc.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep -- Least Authority Enterprises

https://leastauthority.com

Received on Saturday, 19 May 2012 05:41:33 UTC