- From: Jeffrey Walton <noloader@gmail.com>
- Date: Wed, 29 May 2013 22:22:12 -0400
- To: WebCrypto Comments <public-webcrypto-comments@w3.org>
Hi All, Is there any interest in providing APIs to validate parameters? 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. 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. So tests like Jacobi and Miller-Rabin are also of interest. Its common to offer validation and levels in other libraries. For example, the Crypto++ library allows a developer to validate an object and specify a level (http://www.cryptopp.com/docs/ref/class_crypto_material.html#aaa7d67d0c12712de0e33713c73f5b718): level denotes the level of thoroughness: 0 - using this object won't cause a crash or exception (rng is ignored) 1 - this object will probably function (encrypt, sign, etc.) correctly (but may not check for weak keys and such) 2 - make sure this object will function correctly, and do reasonable security checks 3 - do checks that may take a long time Offering validation is consistent with the low level API that is taking shape with the WebCrypto API. Finally, other components, such as JOSE (JSON Web Algorithms (JWA), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Signature (JWS)) does not even mention parameter validation. Someone has to do it, and it appears others are expecting someone else to do it. This is the Bystander Effect, and its a known problem in Security Engineering (cf, Gutmann's Engineering Security, p. 82). Jeff
Received on Thursday, 30 May 2013 02:22:43 UTC