W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25706] Incomplete Key Generation Definitions

From: <bugzilla@jessica.w3.org>
Date: Wed, 14 May 2014 16:22:17 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25706-7213-ZH5XukGCDl@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25706

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Kelsey Cairns from comment #0)
> For the AES algorithms and HMAC, the key generation step does not go into
> any more detail than "generate a key." If there is some intended method to
> generate a key, it should be specified. Similarly, if the underlying
> mechanism is intentionally unspecified I think it would be good to clearly
> state that somewhere. A quick search didn't yield anything and the
> discussions in the section on random number generation (including the note
> that the random number generator should not be used for keys) were also not
> helpful.

Can you please provide suggested wording?

Including a normative reference on SP800-133 is undesirable, as it state's
clearly in Section 5 that the RBG should be a FIPS-approved one, which
historically tend to be be weaker in terms of security guarantees. Further, it
also uses terminology identical to the spec with respect to key generation.

Can you explain any concrete concerns about where the language choice here
affects interoperability? Can you explain any concrete concerns about the
implementation that are not, in and of themselves, quality of implementation
issues?

On "quality of implementation" issues, we've counted things such as the quality
of the primality test, the number of bits of entropy, the constant-timedness of
the operations - all things which, from a black box perspective, do not change
the output or interoperability of implementations, and thus are security
concerns with respect to the User Agent, and not to the specification as a
whole.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 14 May 2014 16:22:18 UTC

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