W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: Defaults: Getting concrete (round 2)

From: Wan-Teh Chang <wtc@google.com>
Date: Fri, 19 Apr 2013 15:16:31 -0700
Message-ID: <CALTJjxGMoVyATzO_iJUVeD43ToeEf+UuaK5+_GJPLH5JBnmQ=A@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
On Thu, Apr 18, 2013 at 11:14 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>
> I agree that there are lots of protocols that have defined ways to shove things into the counter and IV fields for CTR and GCM.  They can always override the default.
>
> I'm more concerned about newer protocols that haven't done something similar (and probably don't need to).  Those protocols just need something that meets the security requirements, and it's easy enough for the UA to provide that.
>
> We've also seen that application designers can also get counter/IV generation badly wrong, as with the recent nonce reuse issue in JOSE:
> <http://www.ietf.org/mail-archive/web/jose/current/msg01967.html>
>
> So while you're right that there are protocols that will not make use of the default, I think that newer things can benefit from having a safe default here.

1. Let's first consider the counter field for the CTR mode.

Unless the UA knows about all the CTR mode encryptions that have been
done with the key in question, the UA cannot generate a new counter
value that hasn't been used before.

This requires the UA to be the exclusive user of the key in question.
But if the API allows the key to be exported, the UA won't be the
exclusive user of the key.

2. As to the IV field for GCM, I think the UA can use the RBG-based
construction of the IV in Section 8.2.2 of NIST SP 800-38D. I believe
this is what you proposed.

3. This makes me wonder if an RBG-based construction of the counter
field for the CTR mode would also be acceptable if the probability of
reusing a counter value is low enough.

Wan-Teh
Received on Friday, 19 April 2013 22:16:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC