Re: crypto-ISSUE-27 (aes ctr): Specification of AES-CTR mode counter bits [Web Cryptography API]

On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> I don't think it's enough to specify the length of the counter. SP 800-38A (http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf) allows for more-or-less arbitrary ways of generating counter sequences. Why not just ask for a function that generates counter values? In other words:
>
> dictionary AesCtrParams : AlgorithmParameters {
>   // The initial value of the counter. counter MUST be 16 bytes.
>   ArrayBuffer counter;
>   // A function that implements the desired counter increment rule
>   ArrayBuffer nextCounter(ArrayBuffer currentValue);
> };

Interesting.

I suppose it would work, but a few concerns:

- Since I'm not aware of any APIs that take user-defined callbacks for
counter generation (native code or not), it would require that the
underlying implementation support one of the following:
  a) Defining an arbitrary IV/CTR per-block (the CryptoAPI approach, I believe)
  b) Support ECB mode, so that the user agent/implementation can
compose CTR mode atop of it
- Because the counter generation is defined in JS, every block to be
encrypted would require execution of a JS function.
  * While in theory, this sounds cheap, since most JS engines are
optimizing to native code these days, for implementations that are
multi-process sandboxes (WebKit2, Chromium... not sure about IE/FF
implementation), this may requires some expensive round-trips.
  * Additionally, while native JS is often fast, the interop between
JS<->native binding (DOM or otherwise) can also become a perf pain
point
  * Optimization becomes a size/speed tradeoff. A user agent might
choose to request up to (message size / block size) counters in a
loop, essentially pre-allocating the xor material. Is this acceptable?

That said, I agree that the callback function is much more flexible
than the PKCS#11-like CTR params structure proposed, and it probably
makes the most sense. It'd be nice to be able to offload counter
generation to the underlying implementation (ala PKCS#11), so that
implementations could work with messages rather than blocks, but it's
probably not the end of the world...



>
>
> -----Original Message-----
> From: Web Cryptography Working Group Issue Tracker [mailto:sysbot+tracker@w3.org]
> Sent: Wednesday, August 22, 2012 1:35 PM
> To: public-webcrypto@w3.org
> Subject: crypto-ISSUE-27 (aes ctr): Specification of AES-CTR mode counter bits [Web Cryptography API]
>
> crypto-ISSUE-27 (aes ctr): Specification of AES-CTR mode counter bits [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/27
>
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
>
> Under the AesCtrParams [1], callers can currently specify an initial value for the counter, as well as a length for how many bits are used for the block counter. Such a specification matches the PKCS#11 definition for AES-CTR, although other APIs such as CDSA, CryptoAPI, and CNG, do not support explicit counter mode, and instead only support ECB as a foundation for CTR.
>
> However, by only specifying the length in bits of the counter, it presumes that the counter bits are either in the most-significant or least-significant bytes. Different systems using AES-CTR may place the block counter in different places - some using the MSB, others using the LSB. Thus, should the API specify an 'offset' as well that, when combined with length, gives a clear position of where the block counter is (internally managed by the API), and where the message counter/nonce are (externally managed by the caller)
>
> [1] http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-AesCtrParams
>
>
>
>

Received on Monday, 27 August 2012 18:28:15 UTC