- Sep 01, 2014
-
-
Andrew Poelstra authored
This avoids the overhead of creating and seeding a Fortuna just to do verification.
-
Andrew Poelstra authored
When creating a Secp256k1, we attach a Fortuna CSRNG seeded from the OS RNG, rather than using the OS RNG all the time. This moves the potential RNG failure to the creation of the object, rather than at every single place that keys are generated. It also reduces trust in the operating system RNG. This does mean that Secp256k1::new() now returns an IoResult while the generate_* methods no longer return Results, so this is a breaking change. Also add a benchmark for key generation. On my system I get: test tests::generate_compressed ... bench: 492990 ns/iter (+/- 27981) test tests::generate_uncompressed ... bench: 495148 ns/iter (+/- 29829) Contrast the numbers with OsRng: test tests::generate_compressed ... bench: 66691 ns/iter (+/- 3640) test tests::generate_uncompressed ... bench: 67148 ns/iter (+/- 3806) Not too shabby :) [breaking-change]
-
- Aug 31, 2014
-
-
Andrew Poelstra authored
-
- Aug 30, 2014
-
-
Andrew Poelstra authored
-
- Aug 28, 2014
-
-
Andrew Poelstra authored
Make sure that you cannot create an invalid `SecretKey` in the first place. Unbreaks the API. [unbreaking-change]
-
Andrew Poelstra authored
It turns out I need to run `init` before pretty-much every FFI function, which means that most everything would have to be marked unsafe if I'm expecting the Rust user to do this. This is unacceptable -- users who need to sacrifice safety for speed can just use the `ffi::` functions instead. Also, I noticed that I was locking up in `PublicKey::from_secret_key`. Fix to return an error value -- unfortunately a breaking change since it changes the function signature. [breaking-change]
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Aug 27, 2014
-
-
Andrew Poelstra authored
-
- Aug 24, 2014
-
-
Andrew Poelstra authored
-
- Aug 18, 2014
-
-
Andrew Poelstra authored
-
- Aug 16, 2014
-
-
Andrew Poelstra authored
Simpler `random_32_bytes`.
-
Dawid Ciężarkiewicz authored
-
Andrew Poelstra authored
As @dpc observes, embedded systems do not necessarily have allocators, so we should avoid using them if it is not too much hassle. (And it is no hassle at all.)
-
- Aug 12, 2014
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
Verifying signatures does not require any randomness, but requires the user to create a `Secp256k1` object nonetheless (this is just a way to guarantee that `init` is called --- an alternate API would be to have an independent unsafe `verify` function). If a Rng can't be created, rather than failing the `Secp256k1` initialization, fail the functions that actually try to use the Rng. This way signing and verifying, which require no randomness beyond that input to them, will work correctly. To avoid checking for a working Rng on each call to `generate_keypair` and `generate_nonce` (which is probably trivial next to the cost of actually generating the randomness, but w/e, user knows best), the user should use the generation functions in the `key` module, which take an Rng as input.
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Aug 10, 2014
-
-
Dawid Ciężarkiewicz authored
-
- Aug 05, 2014
-
-
Dawid Ciężarkiewicz authored
Fix unused imports and add a gitignore
-
- Aug 04, 2014
-
-
Steve Klabnik authored
-
Steve Klabnik authored
-
Dawid Ciężarkiewicz authored
The way compact signatures are working was explain to me: https://github.com/bitcoin/secp256k1/issues/45
-
- Jul 23, 2014
-
-
Dawid Ciężarkiewicz authored
-
- Jul 07, 2014
-
-
Dawid Ciężarkiewicz authored
-