Document assumptions #242

1. 
   gmaxwell commented at 12:42 AM on April 20, 2015: contributor

   The library should provide clear documentation of the strong assumptions that the libraries security rest on. E.g.

   • Secret keys are chosen uniformly at random and in an unpredictable way.
   • Message hashes are the output of a cryptographic hash. (In particular, you can't be caused to sign 0 or verify the signature of 0 (which can be trivially forged))
   • You correctly check the return values of the functions, and correctly supply their inputs
   • The C compiler or computer has not undermined the operation of the software
   • The authors and reviewers of the software made no errors which are not detected by the included tests
   • You obtained a faithful copy of the software
   • Your computers operation is not excessively observable or modifiable by an attacker.
   • The discrete Log problem is hard for the secp256k1 algebraic group
   • The ECDSA signature algorithm is as strong as the discrete log problem

   etc.

2. 
   dcousens commented at 1:40 AM on April 20, 2015: contributor

   Secret keys are chosen uniformly at random and in an unpredictable way.

   Perhaps provide a link to where the randomness is mixed in, and its source?

3. 
   gmaxwell commented at 3:23 AM on April 20, 2015: contributor

   There is no randomness mixed in. The caller provides the private key and the caller must get it right or the security will not hold. :)

4. 
   dcousens commented at 3:25 AM on April 20, 2015: contributor

   Ah, I should have re-read that in context of "assumptions made by the library".

5. 
   gmaxwell commented at 10:43 PM on May 3, 2015: contributor

   More assumptions:

   • The CTX modifying functions will only be performed by callers with exclusive access to the object.
6. 
   gmaxwell commented at 11:12 PM on May 3, 2015: contributor

   • Libsecp256k1 will internally detect some serious impossible conditions (reachable only with miscompilation, processor malfunction, or memory corruption; or a severe mistake on the part of the authors of libsecp256k1 ) and will exit via function(). If total program failure is not a "fail safe" mode for your application, the user will modify function() to do something else.
7. gmaxwell added this to the milestone initial release on Aug 27, 2015
8. 
   gmaxwell commented at 7:04 PM on September 17, 2015: contributor

   include security assumptions for the message hash (e.g. sha-1's believed 2^64 security against collisions is not good.)

9. 
   gmaxwell commented at 6:16 PM on October 10, 2015: contributor

   The C compiler or computer has not undermined the operation of the software

   This should explain more that its not possible to write provably constant time code in C.

Contributors

gmaxwelldcousens

Milestone
stable release (1.0.0-rc.1)