Turns out you cannot initialize constant SecretKeys in any way; these
two constants should cover most sane use cases (other good choices
are the SECG generator and the Alpha CT generator, but these will
wait for a major CT-supporting upgrade, unless demand for them appears.)
We had added a necessary include directory to build.rs but not updated the
library on crates.io, so dependencies of rust-secp were failing to build.
(However, on my local system I had secp installed in /usr/local/include,
so I did not notice the problem until Travis pointed it out on a different
project!)
Pieter moved some stuff I need into the contrib/ directory which does
not expose anything through the shared lib, so I need to statically
link.
I might also use this to do evil things to expose the SHA256 code
in libsecp, but not for now ;).
This should be a major version number since I changed public constants
in the ffi module. I'm not doing so as the invariant "will the constants
be meaningful to the underlying library" has not changed.
In general this library's version numbers do not map well to the
underlying library, which is as-yet not versioned at all, so users
need to always be running "the lastest" rust-secp256k1 anyway, and
semantic versioning can't really be used meaninfully. So this is a
bit of a judgement call.
If you try to call PublicKey::from_secret() key with an incapable context it will
now return an error. Before it would pass through to the underlying library which
would terminate the process, something we strive to never expose.
Also change the from_ffi functions on various types to impl's of From to be more
Rustic. We cannot change the from_slice functions because they have error returns.
Also add a Secp256k1::without_caps() function which creates a capability-less
context. I find myself using this in so many places downstream that it seems
appropriate.
This reverts commit 9889090784.
This is not ready for primetime -- the move prevention also prevents
reborrowing, which makes secret keys nearly unusable.
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.
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]
Andrew Poelstra
Dawid Ciężarkiewicz