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

On Mon, Oct 15, 2012 at 8:12 AM, Wan-Teh Chang <wtc@google.com> wrote:
> Proposed resolution of crypto-ISSUE-27 (aes ctr):
>
> In section 23.9.3 of the FPWD. the AesCtrParams dictionary is
> specified as follows:
>
> dictionary AesCtrParams : AlgorithmParameters {
>   // The initial value of the counter. counter MUST be 16 bytes.
>   ArrayBuffer counter;
>   // The length, in bits, of the counter
>   [EnforceRange] octet length;
> };
>
> I proposed that it be changed to:
>
> dictionary AesCtrParams : AlgorithmParameters {
>   // The initial value of the counter block. counterBlock MUST be 16
>   // bytes (the AES block size). The counter bits are the rightmost
>   // counterBitsLength 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.
>   ArrayBuffer counterBlock;
>
>   // The number of bits in the counter block that shall be incremented.
>   [EnforceRange] octet counterBitsLength;
> };
>
> Note that the following two aspects are hardcoded:
> 1. The counter bits must be the rightmost bits.
> 2. The incrementing function must be the standard incrementing
>    function, which treats the counter bits as a big-endian integer
>    and increments them by one.
>
> Wan-Teh

Was there a reason for the naming change?

As mentioned on previous calls, this is something that won't be able
to be minified (the literal strings "counter" and "length" will have
to appear in the final dictionary), thus the "counterBlock" and
"counterBitsLength" seem... overly long?

Received on Monday, 15 October 2012 16:25:31 UTC