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

Richard,

Can you confirm that your intent is that the generated value is
returned via the algorithm attribute of the CryptoOperation?

If so, it seems very inappropriate for use in ConcatParams and
Pbkdf2Params - as both of those vend KeyOperations (aka Futures - aka
Promises) - that is, simple asynchronous wrapped values.

It also further strikes me as dangerous because the returned Algorithm
(as part of the CryptoOperation) does not match the original inputs.
If an implementation attempts to re-use the Algorithm, expecting a
"new" random IV will be generated (in keeping in line with the
original creation parameters), they will be in for cryptosystem
failure.

I still have strong reservations against such syntactic sugar. The
combination with AesCtr, for example, allows for even greater chance
of misuse, because it fully divorces the caller from the notion of
maintaining a counter and guaranteeing values do not repeat.

In this sense, I think the only possible places it COULD be used
safely was in AesCbc/AesCfb - that is, I would not consider this for
AesGcm either.

Because of this, I think it's a proposal of limited value, and only
serves to increase risk. Put differently, I do not believe anyone who
knows what they're doing should use this method, and as such, it will
only be used by people who don't know what they're doing - thus
leaving it to be used incorrectly.

On Mon, May 27, 2013 at 7:23 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> 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 Tuesday, 28 May 2013 17:28:25 UTC