- From: Jeffrey Walton <noloader@gmail.com>
- Date: Wed, 29 May 2013 23:20:21 -0400
- To: Ryan Sleevi <sleevi@google.com>
- Cc: WebCrypto Comments <public-webcrypto-comments@w3.org>
On Wed, May 29, 2013 at 10:44 PM, Ryan Sleevi <sleevi@google.com> wrote: > > On May 29, 2013 7:22 PM, "Jeffrey Walton" <noloader@gmail.com> wrote: > >> ... >> One of the things I try and teach my guys is that they must validate >> cryptographic parameters; and they cannot apply a secret if validation >> fails. Unvalidated keys could have flaws that allow for recovery of >> the secret. For example, if an RSA public key does not validate, then >> it should not be used to transport a secret. > > Define your threat model. Where do such keys come from. Why are they not > trusted - and yet being used to transfer secrets? Seems a conflicting > statement. What I have in mind is (1) weak keys due to bad generators (Debian, NetBSD, OpenSSL, etc) and (2) weak keys due to bad algorithms and/or lack of validation. Not everyone uses hardware rngs to seed /dev/{u}random, not everyone uses "well known" libraries for generation (confer, the small percentage of non-standard public exponents), and not everyone performs rigorous testing before publishing their public keys. >> GnuPG is a somewhat special case since its key pair is composed of >> Lim-Lee primes. In this case, we can apply a "small prime" test; but >> not a "strong prime" test. >> >> Taking both standard practices and GnuPG into consideration, I believe >> that means the API should accept a level for validation. Arbitrarily, >> levels should probably follow the model set by certificate classes (1 >> = low, N = high), so a Level 0 would mean no validation; Level 1 >> validation would perform the small prime test; Level 2 would perform >> the strong prime test (plus level 1), Level 3 could provide the tests >> that take prolonged time (plus Level 2). >> >> Its probably worth mentioning that local keys should be validated too >> - for example, after loading a private key from a key store. > > Why? What's the threat model for this case? Three concerns here: (1) a key was previously stored without proper validation; and (2) an inadvertent transformation on the material; or (3) an inadvertent bit flip (storage, bus, or memory). In all cases, I don't want to apply secrets to unvalidated parameters. Jeff
Received on Thursday, 30 May 2013 03:20:51 UTC