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

On Tue, May 15, 2012 at 9:44 AM, Zooko Wilcox-OHearn
<zooko@leastauthority.com> wrote:
> 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     |

Hmm... I realize that many people would prefer we only use EC, but I'm
having a lot of trouble understanding the usefulness of a crypto API
which can't interoperate with the vast majority of cryptographic systems
in current deployment, which generally use RSA and/or DH.

-Ekr

Received on Monday, 21 May 2012 16:18:04 UTC