RE: AES-GCM Algorithm is missing tag properties for input params and result value

JOSE rejected using RFC 5116 encodings because the library implementations of the existing authenticated encryption algorithms almost always provide separate inputs for the key, initialization vector, and plaintext, and separate outputs for the ciphertext and authentication tag.  It's therefore a more natural mapping from existing crypto libraries to the JOSE encoding by not combining any of the inputs or outputs, as RFC 5116 proposes to do - making life easier for implementers.

Also, by not making assumptions about how long the IV and tag values are (which is required if you're going to use RFC 5116), we can support the full generality of the legal inputs and outputs of GCM and other authenticated encryption algorithms.  Otherwise, you have to, for instance, fix the IV to 96 bits and the tag to 128 bits, which is a fine set of defaults, but not always how the algorithms are used in practice.  WebCrypto, being a low-level API, should support the general form, where the sizes of the IV and tag are chosen by the caller, rather than an RFC 5116 specialization of the algorithms.

                                             -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, May 09, 2013 10:33 PM
To: Mike Jones
Cc: Marcin Stankiewicz; public-webcrypto@w3.org; Israel Hilerio
Subject: RE: AES-GCM Algorithm is missing tag properties for input params and result value


Mike,

Can you explain why?
On May 9, 2013 10:09 PM, "Mike Jones" <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
JOSE decided to keep the tag separate and not use RFC 5116. I think we should too.

-- Mike
________________________________
From: Ryan Sleevi
Sent: 5/9/2013 5:36 PM
To: Israel Hilerio
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>; Marcin Stankiewicz
Subject: Re: AES-GCM Algorithm is missing tag properties for input params and  result value
On Thu, May 9, 2013 at 5:13 PM, Israel Hilerio <israelh@microsoft.com<mailto:israelh@microsoft.com>> wrote:
> Another piece of feedback we provided during the F2F was that the input parameters for AES-GCM need a tag property and the result value for AES-GCM needs to contain a tag parameter in addition to the ciphertext.
>
> This implies that we'll need to update the AesGcmParams dictionary the following way:
>
> dictionary AesGcmParams : Algorithm {
>   // The initialization vector to use. May be up to 2^56 bytes long.
>   ArrayBufferView? iv;
>   // The additional authentication data to include.
>   ArrayBufferView? additionalData;
>   // The desired length of the authentication tag. May be 0 - 128.
>   [EnforceRange] octet? tagLength;
>
>
>   // The authentication tag value for decryption
>   ArrayBufferView? tag;
>
>
> };

If we go this route, I would rather see two dictionaries, so that it
can be unambiguous that tag is required for decrypt, but not for
encrypt.

>
> This changes will impact section 20.12.3 of the spec.
>
> In addition, since we can't return dictionaries I was thinking we could add a new interface:
>
> interface AesGcmResult {
>         readonly attribute ArrayBuffer? tag;
>         readonly attribute ArrayBuffer ciphertext;
> }
>
> This will impact the result values of section 20.12 AES-GCM registration table. We'll have to return this new interface for encrypt only.  Alternatively, we could return it also for decrypt with the tag value being null or set from the input parameter.

Agreed on this affecting encrypt only.

>
> Let us know what you think.
>
> Thanks,
>
> Israel
>
>

I seem to recall some discussion/debate about whether or not it should
follow the mode of RFC5116/PKCS#11 and treat the tag as a suffix of
the ciphertext. I believe Richard was a proponent of this, and that
certainly reflects the 'intent' of the current spec (although, as we
both noted - presently woefully underspecified)

The benefit of that is similar to those benefits expounded upon in
RFC5116 - it treats AEAD encryption using a consistent interface as
non-authenticated encryption, at least in terms of inputs/outputs.

I'm curious for the arguments for splitting them up, since we did not
have sufficient time during the F2F to discuss this point. Is there a
technical advantage, or is this for syntactic purposes?