1 # Project Wycheproof 2 3 This page describes the goals and strategies of project Wycheproof. See 4 [README](../README.md) for an introduction to the project. 5 6 ## Defense in depth 7 8 There are a number of tests where we check for expected behaviour 9 rather than exploitability. Examples: 10 11 * default values: we expect that default values are reasonable and correspond 12 to recommendations by current standards. Concretely, in 2016 it is not OK 13 if an RSA key generation uses 1024 bits as default or digital signatures 14 use SHA-1 as default. 15 * timing attacks: any timing that relation between keys (or other sensitive) 16 data and the measured time fails the test. However tests are set up 17 such that too much noise during the test can prevent that a relation 18 is detected. 19 * wrong exceptions: The JCE interface often specifies the exceptions that 20 should be thrown when the input is invalid. We expect the specified 21 exceptions in the tests. 22 * leaking information through exceptions: While it is a good practice to not 23 return detailed logs to a sender, we consider text in exceptions as 24 information that a potential attacker can learn. For example padding 25 failures during decryption should not contain information about the 26 reason why a decryption failed. 27 * RSA PKCS #1 signatures: If a signature verification allows signatures 28 with lots of modifications, then RSA signatures can be forged for small 29 public exponents. Tests do not measure how many bytes can be modified. 30 Any accepted modification of the PKCS #1 padding fails the test. 31 32 ## Compatibility between providers 33 34 One of the goals of Wycheproof is to test for compatibility issues. 35 Switching JCE providers should not introduce vulnerabilities simply because 36 the solution was developed by another provider. 37 38 An example for this was the following observation: When using AES-GCM then 39 javax.crypto.CipherInputStream worked sort of with JCE and 40 org.bouncycastle.jcajce.io.CipherInputStream.java worked with BouncyCastle. 41 However, authentication was skipped in some cases when 42 javax.crypto.CipherInputStream was used with BouncyCastle. 43 44 ## Comparing cryptographic libraries is not a primary goal 45 46 Because of the strategies mentioned above we expect that a comparison of 47 cryptographic libraries based on the bugs found would be biased: 48 49 * Libraries used internally in Google get more attention. 50 Serious vulnerabilities in these libraries should be fixed at the time the 51 tests are added to Wycheproof. On the other hand it is also likely that 52 tests find a larger number of bugs in these libraries when old versions are 53 tested. 54 * Tests often check for expected behaviour and compatibility. 55 Expected behaviour is often defined by a prominent library. 56 Pointing out such problems can therefore penalize smaller third party 57 libraries. 58 * We are working toward covering as many potential vulnerabilities as possible 59 with test vectors, because this simplifies porting the tests to other 60 languages or interfaces. Thus a single test case can cover multiple 61 vulnerabilities. 62 63 We are not trying to remove this bias when this interferes with more important 64 goals such as early reporting. 65 Hence we are reluctant to publish comparisons. 66 67 68 ## Thoughts on the design of cryptographic libraries 69 70 We should promote robust interfaces with the goal to simplify 71 the use of the library, code reviews of applications using the 72 library and testing the library. 73 74 * When cryptographic primitives require randomness then the random 75 numbers should be chosen by the library. It shouldn't be possible 76 for a user to provide randomness. If the library itself chooses the 77 randomness then it is possible (at least to some degree) to check 78 that the random number generation is appropriate for the primitive. 79 If the user can provide the randomness then it is not possible to 80 catch this in our tests. 81
