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> 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?

Received on Friday, 10 May 2013 00:36:07 UTC