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

Re: Defaults: Getting concrete (round 2)

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 17 Apr 2013 18:17:31 -0700
Message-ID: <CACvaWvZCMmnQzZsuTnTKQEyrv7ADByctczwwdJB_dqNttYASWA@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
I wouldn't call the feedback lukewarm. I could call it definitively negative.

I still do not support defaults. For all the reasons that have been
discussed and from the public comments.

On Wed, Apr 17, 2013 at 5:43 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> In light of the few bits of lukewarm feedback on the last concrete proposal on defaults, I would like to make a more focused proposal on the default values that I think are (1) the most obvious, and (2) the most likely to hurt developers.  Namely, IVs for the various AES modes.  Details follow; comments welcome!
>
> Thanks,
> --Richard
>
>
>
> Summary:
>
> Add default values for the "iv" parameters in AesCbcParams, AesCfbParams, AesCtrParams, and AesGcmParams.  During the "parameter normalization" step, these parameters are set by the UA to values meeting the requirements of the relevant NIST specifications.
>
>
> I. Background: NIST Requirements
>
> The standards for CBC, CFB, and CTR modes is NIST SP800-38A; for GCM, it's SP800-38D.  Here are the relevant requirements for IVs:
>
> SP800-38A
> """
> For the CBC and CFB modes, the IVs must be unpredictable. In particular, for any given plaintext, it must not be possible to predict the IV that will be associated to the plaintext in advance of the generation of the IV.
> ...
> [For CTR,]The initial counter blocks, T1, for each message that is encrypted under the given key must be chosen in a manner than ensures the uniqueness of all the counter blocks across all the messages.
> """
>
> SP800-38D
> """
> The probability that the authenticated encryption function ever will be invoked with the same IV and the same key on two (or more) distinct sets of input data shall be no greater than 2^-32.
> """
>
> The thing to observe here is that the UA can trivially generate IVs that meet these requirements.  For CBC, CFB, and GCM, simply generating pseudo-random value for each call to encrypt() suffices; for CTR, the UA might need to keep a counter with the key to generate message nonces that are guaranteed to unique.  Given that implementing this is so simple and makes it significantly easier to operate securely, we should require the UA to do it.
>
>
>
> II. Proposed Revision to Specification
>
> This proposal puts the requirements for UAs to generate values in the IDL describing the parameter dictionaries.  It might be more appropriate to put it somewhere else, e.g., in encrypt().  For brevity, I've only copied in the revised IDL here; changed lines are marked with "XXX".
>
> -----BEGIN-----
> dictionary AesCbcParams : AlgorithmParameters {
>   // The initialization vector. MUST be 16 bytes.
>   // If not present, MUST be set on normalization to a random value     XXX
>   ArrayBufferView? iv;                                                  XXX
> };
>
> dictionary AesCfbParams : AlgorithmParameters {
>   // The initialization vector. MUST be 16 bytes.
>   // If not present, MUST be set on normalization to a random value     XXX
>   ArrayBufferView? iv;                                                  XXX
> };
>
> dictionary AesCtrParams : AlgorithmParameters {
>   // The initial value of the counter block. counter MUST be 16 bytes
>   // (the AES block size). The counter bits are the rightmost length
>   // bits of the counter block. The rest of the counter block is for
>   // the nonce. The counter bits are incremented using the standard
>   // incrementing function specified in NIST SP 800-38A Appendix B.1:
>   // the counter bits are interpreted as a big-endian integer and
>   // incremented by one.
>   // If not present, MUST be set on normalization to a UA-selected      XXX
>   // value meeting the criteria of NIST SP 800-38A Appendix B.2         XXX
>   ArrayBuffer? counter;                                                 XXX
>   // The length, in bits, of the rightmost part of the counter block
>   // that is incremented.
>   [EnforceRange] octet length;
> };
>
> dictionary AesGcmParams : AlgorithmParameters {
>   // The initialization vector to use. May be up to 2^56 bytes long.
>   // If not present, MUST be set to a random value on normalization,    XXX
>   //    of a length chosen by the UA                                    XXX
>   ArrayBufferView? iv;                                                  XXX
>   // The additional authentication data to include.
>   ArrayBufferView? additionalData;
>   // The desired length of the authentication tag. May be 0 - 128.
>   [EnforceRange] octet? tagLength = 0;
> };
> -----END-----
>
>
>
Received on Thursday, 18 April 2013 01:17:58 UTC

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