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

The Microsoft providers in CryptoAPI and CNG don't really support CTR natively - an application has to build it on top of ECB. An application doing this would likely create a large block of counters, encrypt it with ECB, then XOR it to the message. CNG does support GCM and CCM, with fixed increment rules.

I'm not wedded to the callback solution, but I only see three choices here:

1. Ask for an IV, allow the caller to choose between a small set of increment rules (maybe just one even).
2. Ask for a block of counters, only encrypt a message of that length (impractical if you're doing streaming audio or video).
3. Ask for a callback, perhaps one that allows the UA to specify a number of counters requested.

The simplest approach for an implementer is actually to specify #1 with a fixed increment rule, and let callers build the rest on top of ECB. The most general is #3.

The advantage of #1 is that it allows the underlying implementation to optimize better and can take advantage of certifications (e.g. FIPS 140 validation) of the underlying CTR implementation. So, rethinking my earlier proposal, perhaps it is better to go with #1 for now and see what the community says?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, August 27, 2012 11:28 AM
To: Vijay Bharadwaj
Cc: Web Cryptography Working Group
Subject: 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 Tuesday, 28 August 2012 13:40:46 UTC