On Mon, Feb 24, 2014 at 12:10 PM, Vijay Bharadwaj < 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.
Received on Monday, 24 February 2014 20:15:24 UTC