On Mon, Feb 24, 2014 at 8:46 AM, Vijay Bharadwaj < Vijay.Bharadwaj@microsoft.com> wrote: > [Mark]> So, it's ambiguous to me whether an implementation should > consider it an error if the length choice combined with the message size > will cause the same counter value to be repeated. > > > > [Mark]> What we should probably look at is what existing library > implementations do. If some implementations consider this an error - and > fail - then it would improve interoperability if WebCrypto would always > fail in this case by including the length check described. If no existing > implementations consider this an error, then it should be left to the > application as only the application can fully policy the requirement across > messages. > > > > Windows crypto APIs (CAPI and CNG) do not expose CTR mode except as a > component of GCM or CCM. However it does seem to me like the counter > increment rule and message size give a way for the implementation to > identify some cases of insecure usage. It seems reasonable to block these > cases – I don’t see any legitimate use for them. > I would have to disagree here. A given Key object can be used for multiple Encryption operations. Further, a Key may wrap-around the counter - there's no guarantee that the counter started initialized to an all zero block, so it's not sufficient to look at whether the high-bit+1 is set when incrementing. This is exactly why PKCS#11 (NSS) and OpenSSL allow it. I definitely think it should be left up to the implementation. To me, this is conceptually the same as supporting non-mod-8 RSA moduli. Some implementations do, some don't.
Received on Monday, 24 February 2014 18:38:37 UTC