- Apr 12, 2015
-
-
Andrew Poelstra authored
This function can't fail, so no need to return a Result.
-
- Apr 11, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
All of these were things that are (should be) guaranteed true no matter what input is given to the API, barring unsafe operations on the data.
-
Andrew Poelstra authored
Now that you can't create secret keys by directly passing a Rng to `SecretKey::new`, we need a way to allow user-chosed randomness. We add it to the `Secp256k1`.
-
Andrew Poelstra authored
Rather than have global initialization functions, which required expensive synchronization on the part of the Rust library, libsecp256k1 now carries its context in thread-local data which must be passed to every function. What this means for the rust-secp256k1 API is: - Most functions on `PublicKey` and `SecretKey` now require a `Secp256k1` to be given to them. - `Secp256k1::verify` and `::verify_raw` now take a `&self` - `SecretKey::new` now takes a `Secp256k1` rather than a Rng; a future commit will allow specifying the Rng in the `Secp256k1` so that functionality is not lost. - The FFI functions have all changed to take a context argument - `secp256k1::init()` is gone, as is the dependency on std::sync - There is a `ffi::Context` type which must be handled carefully by anyone using it directly (hopefully nobody :))
-
Andrew Poelstra authored
Y'know, I can't for the life of me think what this was supposed to be used for. Given that the library did not compile for several months until last week, I assume there are no users, let alone users of such a weird feature.
-
- Apr 10, 2015
-
-
Andrew Poelstra authored
-
- Apr 09, 2015
-
-
Andrew Poelstra authored
-
- Apr 06, 2015
-
-
Andrew Poelstra authored
rust-secp256k1 was based off of https://github.com/sipa/secp256k1, which has been inactive nearly as long as this repository (prior to a couple days ago anyway). The correct repository is https://github.com/bitcoin/secp256k1 This is a major breaking change to the library for one reason: there are no longer any Nonce types in the safe interface. The signing functions do not take a nonce; this is generated internally. This also means that I was able to drop all my RFC6979 code, since libsecp256k1 has its own implementation. If you need to generate your own nonces, you need to create an unsafe function of type `ffi::NonceFn`, then pass it to the appropriate functions in the `ffi` module. There is no safe interface for doing this, deliberately: there is basically no need to directly fiddle with nonces ever.
-
Andrew Poelstra authored
-
- Apr 05, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Apr 04, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Mar 26, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Mar 25, 2015
-
-
Andrew Poelstra authored
-
Andrew Poelstra authored
I'm taking advantage of the CC0 license on any of David's code to give me permission to do this :). Almost all of it is my code by this point so I am also morally in the clear. -a
-
Andrew Poelstra authored
-
Andrew Poelstra authored
[breaking-change]
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Jan 17, 2015
-
-
Andrew Poelstra authored
All tests pass, compile now
-
Andrew Poelstra authored
We can compile now, but not link -- there have been too many changes in libsecp256k1 behind the scenes. Next commit :)
-
- Sep 12, 2014
-
-
Andrew Poelstra authored
This reverts commit 98890907. This is not ready for primetime -- the move prevention also prevents reborrowing, which makes secret keys nearly unusable.
-
Andrew Poelstra authored
Using the `secretdata` library, we can store SecretKeys in such a way that they cannot be moved or copied, and their memory is zeroed out on drop. This gives us some assurance that in the case of memory unsafety, there is not secret key data lying around anywhere that we don't expect. Unfortunately, it means that we cannot construct secret keys and then return them, which forces the interface to change a fair bit. I removed the `generate_keypair` function from Secp256k1, then `generate_nonce` for symmetry, then dropped the `Secp256k1` struct entirely because it turned out that none of the remaining functions used the `self` param. So here we are. I bumped the version number. Sorry about this.
-
- Sep 05, 2014
-
-
Andrew Poelstra authored
The typesafe version could not accept illegally padded signatures because `Signature` is a fixed-width type. Unfortunately such signatures are on the blockchain, and we need a way to verify them.
-
Andrew Poelstra authored
-
Andrew Poelstra authored
-
- Sep 04, 2014
-
-
Andrew Poelstra authored
Testing was done against python-ecdsa; python code in the test case comments.
-
Andrew Poelstra authored
[breaking-change]
-
- Sep 01, 2014
-
-
Andrew Poelstra authored
-
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]
-