Re: API for Validating Crypto Parameters

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