RE: Bug # 24410 - AES CTR descriptions

To be clear, I am not proposing any bookkeeping. The question is whether we want to add a step 3.5 in 18.10.6:

If 2^length is less than (length of plaintext in bytes)/16, terminate this algorithm with an error.

As I said, the Windows implementation does not expose CTR in CNG. However, were we to add it, I think we would follow the text in SP800-38A and implement this sanity check. The NIST validation suite for AES seems to suggest that labs check for this (see http://csrc.nist.gov/groups/STM/cavp/documents/aes/AESAVS.pdf Appendix A) so it is likely that an implementation that does not do this would face difficulties in FIPS validation.



From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, February 24, 2014 12:15 PM
To: Vijay Bharadwaj
Cc: Mark Watson; Jim Schaad; public-webcrypto@w3.org
Subject: Re: Bug # 24410 - AES CTR descriptions



On Mon, Feb 24, 2014 at 12:10 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
I agree that the implementation cannot detect all cases of counter wrap.

The question is, should it error out in the cases where it can? What is the counter-argument – is it that there is a legitimate use for counter wrap, or is it that catching some cases gives a false sense of security?


I think the actual number of situations where an implementation can detect counter wrap to be fairly low. I can certainly state that the bookkeeping overhead of (reliably) implementing counter-wrap is such that it's unlikely to be implemented within Chromium, and I would be quite surprised if any other implementations did - because it's something that none of their underlying cryptographic libraries 'natively' support (for exactly the same reason).

So it's just a matter of whether or not the current definition of the AES-et-al methods 'permit' an implementation to implement such detection, if they could. I think the definitions currently provide the latitude to allow it - again, using the same argument as odd-bits of RSA moduli or 'internal' library errors.

I think it'd be a bad idea for the spec to recommend or suggest something that would not / cannot be widely implemented.