W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

ACTION-86: Make a proposal for an explicit auto generation token for IV

From: Richard Barnes <rbarnes@bbn.com>
Date: Mon, 27 May 2013 10:23:00 -0400
Message-Id: <42B2148F-E206-4E43-885B-AAD3F1D6DBAB@bbn.com>
To: "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
At the F2F, I was assigned ACTION-86 to propose a syntax for auto-generation of IVs, indicated via an explicit token.  A proposal is below. 

As I was writing, it occurred to me that a "generate a random string of appropriate length" primitive could be useful in other contexts as well.  For example, in generating salt for KDFs.  I have written the below with that level of generality in mind.  If that makes people uncomfortable, however, I would be OK with limiting this to IVs.  (s/RandomValue/InitializationVector/g).

TL;DR: We define an AutoGenMethod enum that can be used in place of ArrayBufferView, so for example:

var gcm = { name: "AES-GCM", iv: "random" };
var pbkdf2 = { name: "PBKDF2", salt: "random", prf: "SHA-256" };

Then the values for those fields are auto-generated on each creation of a CryptoOperation with that algorithm.

Feedback welcome!  And expected :)

Thanks,
--Richard



PART 1: Algorithm Identifier Syntax

In Section 10. Algorithm Dictionary, add the following IDL:

~~~~~~~~~~
enum AutoGenMethod {
    // Generate a random initialization vector
    // on each invocation using this algorithm structure
    "random"
};
typedef (ArrayBufferView or AutoGenMethod) RandomValue;
~~~~~~~~~~

Adapt the various *Params interfaces to use RandomValue.  
-- AesCbcParams.iv
-- AesCfbParams.iv
-- AesCtrParams.counter
-- AesGcmparams.iv
-- ConcatParams.partyUInfo 
-- Pbkdf2Params.salt

For example:
~~~~~~~~~~
dictionary AesGcmParams : Algorithm {
  // The initialization vector to use. May be up to 2^56 bytes long.
  RandomValue iv;
  // The additional authentication data to include.
  ArrayBufferView? additionalData;
  // The desired length of the authentication tag. May be 0 - 128.
  [EnforceRange] octet? tagLength;
};
~~~~~~~~~~


PART 2: Algorithm Identifier Processing

In Section 10 (Algorithm dictionary), add a summary of how RandomValue works:
"""
Applications can ask the UA to set RandomValue fields on their behalf.  Each time a CryptoOperation is created using a given Algorithm structure, the UA generates a fresh ArrayBufferView value for each RandomValue field with an AutoGenMethod value, according to the specified AutoGenMethod.  So if the AutoGenMethod is "random", then the UA generates a random string of appropriate length.  (Obviously, if a RandomValue field is already set to an ArrayBufferView value, then the value is not changed.)
"""

In each CryptoOperation method (Section 15.2) add an auto-generate step after algorithm normalization and support checking (after step 2 in the encrypt method):
"""
X. For each field in /normalizedAlgorithm/ that is of type RandomValue:
X.1. If the field contains an ArrayBufferView value, continue
X.2. Else if the field contains an AutoGenMethod value, generate a new value according to the specified AutoGenMethod, and set the field to that value
"""
(Or, alternatively, define a subroutine like normalization that handles this.)
Received on Monday, 27 May 2013 14:24:07 UTC

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