Re: using authenticated encryption in webcrypto

Hi Ryan,

On Jun 15, 2012, at 2:27 PM, Ryan Sleevi wrote:
> 
> 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.

good question.   What I meant is that by using the same AEAD API for CBC-HMAC, we can provide the implementer with access to most of the encryption algorithms of interest through a uniform interface.  But you are right that as long as raw CBC is present the API is not smaller.

> 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 either.

We could potentially lose those interfaces.   Key wrapping would be simple to eliminate: it is essentially authenticated encryption, and the AES KeyWrap algorithm could use the AEAD API, though it has security properties that are weaker than other AEAD algorithms that would need to be documented (e.g. only 64 bits of authentication strength).   The AES SIV mode of operation, which has been proposed as a replacement for AESKW, has already been given code points in the IANA AEAD registry <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml>

You are right that asymmetric authentication will be needed, and combining that operation with AEAD gives double authentication.  I would guess that this combination is not a significant performance impact, and there might be scenarios in which double authentication is advantageous (say, chosen ciphertext timing attacks), but I have not studied this closely.

David

> 
> Have I missed something fundamental in your proposal?
> 
> Cheers,
> Ryan
> 

Received on Monday, 18 June 2012 10:42:01 UTC