W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: using authenticated encryption in webcrypto

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 15 Jun 2012 11:27:49 -0700
Message-ID: <CACvaWvZ5==bQvTjVa6V6WUkDWO46k9aOmUAp1s8ZLgHNnZK5qQ@mail.gmail.com>
To: David McGrew <mcgrew@cisco.com>
Cc: public-webcrypto@w3.org, Kenny Paterson <Kenny.Paterson@rhul.ac.uk>
On Fri, Jun 15, 2012 at 9:24 AM, David McGrew <mcgrew@cisco.com> wrote:

> Hi,
> I propose that webcrypto encourage the use of authenticated encryption
> with associated data (AEAD) instead of non-authenticated symmetric
> encryption such as raw CBC mode.   From a security perspective, it would be
> best to only allow encryption that is tightly bound to authentication, but
> I am suggesting that the standard make AEAD a should-implement and not a
> must-implement for the obvious reason of backwards compatibility with
> existing implementations.
> There are dedicated AEAD modes like CCM and GCM, but some implementations
> may want to use CBC and HMAC because those modes are already implemented,
> or because the do not want to manage the deterministic nonces that CCM and
> GCM require.  I recently submitted a draft (joint work with Kenny) that
> defines AEAD algorithms based on CBC and HMAC.   I believe that this work
> would be suitable for use in webcrypto, and would actually simplify the
> API.   For instance, in David Dahl's algorithm ideas, the CBC-HMAC
> algorithms would have the same interface as the GCM algorithm.
> The draft is at <
> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-00>; here
> is the abstract:
>   This document specifies algorithms for authenticated encryption with
>   associated data (AEAD) that are based on the composition of the
>   Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)
>   mode of operation for encryption, and the HMAC-SHA message
>   authentication code (MAC).
>   These are randomized encryption algorithms, and thus are suitable for
>   use with applications that cannot provide distinct nonces to each
>   invocation of the AEAD encrypt operation.
> Comments on the draft itself and on suitability for this WG are welcome.
> I have been on travel recently and I am not caught up with all threads on
> the list yet; apologies if I have missed some prior discussion of these
> points.
> regards,
> David

+1 to supporting AEAD.

However, I'm not sure I'd agree with the statement that simplifies the API
any, so I was hoping you could explain. As I see it, It would only simplify
things if some API was being removed, but I understand that you're
specifically not proposing that non-authenticated encryption be prohibited.
And while AEAD offers compelling properties for tamper resistance, I
imagine there will still be a desire for authenticity checks via asymmetric
keys and/or key wrapping, so we don't necessarily lose those interfaces

Have I missed something fundamental in your proposal?

Received on Friday, 15 June 2012 18:28:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC