Commit Graph

1193 Commits

Author SHA1 Message Date
Andrew Poelstra d2fcbbe95a Change name to secp256k1 from bitcoin-secp256k1-rs
[breaking-change]
2015-03-25 17:20:44 -05:00
Andrew Poelstra 825e77519f for in range(a,b) -> for in a..b 2015-03-25 14:42:05 -05:00
Andrew Poelstra d0519f0b3a IoResult -> io::Result, copy_nonoverlapping_memory -> copy_nonoverlapping 2015-03-25 14:10:02 -05:00
Andrew Poelstra 1e24549ef5 Show -> Debug 2015-03-25 13:59:54 -05:00
Andrew Poelstra 5a6c6c8d0a Fix for secp256k1 ffi changes
All tests pass, compile now
2015-01-17 10:38:16 -06:00
Andrew Poelstra d495d9ca06 Update for rustc changes
We can compile now, but not link -- there have been too many changes
in libsecp256k1 behind the scenes. Next commit :)
2015-01-17 10:13:45 -06:00
Andrew Poelstra 9cab4e023d Revert "Overhaul interface to use zero-on-free SecretKeys"
This reverts commit 9889090784.

This is not ready for primetime -- the move prevention also prevents
reborrowing, which makes secret keys nearly unusable.
2014-09-12 08:28:35 -05:00
Andrew Poelstra 9889090784 Overhaul interface to use zero-on-free SecretKeys
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.
2014-09-12 08:28:26 -05:00
Andrew Poelstra 62504165e4 Reimplement non-typesafe `verify` fn, call it `verify_raw`.
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.
2014-09-04 20:32:49 -05:00
Andrew Poelstra eabe57e403 Also make PublicKey encodable 2014-09-04 20:21:09 -05:00
Andrew Poelstra 71312b032a Impl encodable/decodable for the array newtypes 2014-09-04 20:09:18 -05:00
Andrew Poelstra 17daebf15d Implement deterministic nonce generation with HMAC-SHA512
Testing was done against python-ecdsa; python code in the test case
comments.
2014-09-04 16:21:35 -05:00
Andrew Poelstra 46f646dabb Make `verify` accept a `Signature` rather than a slice
[breaking-change]
2014-09-04 11:52:25 -05:00
Andrew Poelstra 770ebbafc4 Add a `Sequence` iterator for generating sequential keypairs; fix tests 2014-09-01 11:13:31 -05:00
Andrew Poelstra 204524117c Make Secp256k1::verify() static
This avoids the overhead of creating and seeding a Fortuna just to do verification.
2014-08-31 22:33:19 -05:00
Andrew Poelstra d94345f721 Generate keys from Fortuna rather than always using the OsRng
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]
2014-08-31 22:26:02 -05:00
Andrew Poelstra 059c72aa60 Do validation in pubkey::from_slice 2014-08-31 16:04:14 -05:00
Andrew Poelstra a0ecfe9e29 Change lint names for upstream 2014-08-30 07:24:44 -07:00
Andrew Poelstra 15b8183ea8 Remove error return from `PublicKey::from_secret_key()`
Make sure that you cannot create an invalid `SecretKey` in the first place.
Unbreaks the API.

[unbreaking-change]
2014-08-28 11:11:25 -07:00
Andrew Poelstra a67260eb3a Remove unsafe markers and just call `init` everywhere
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]
2014-08-28 10:59:44 -07:00
Andrew Poelstra a5951eff47 Expose tweak functions in FFI, wrap a couple 2014-08-28 09:16:53 -07:00
Andrew Poelstra e13b23d720 Add curve order and generator coordinates to constants 2014-08-27 22:49:22 -07:00
Andrew Poelstra a0f11d0f92 Travis speaks rust now :D 2014-08-27 10:58:24 -07:00
Andrew Poelstra 83f2ccf5d7 Add verification to SecretKey::from_slice() 2014-08-24 16:13:08 -07:00
Andrew Poelstra 79815e225b Add .travis.yml, update tests and Cargo.toml for upstream changes 2014-08-17 18:58:20 -07:00
Andrew Poelstra bf011f956e Merge pull request #2 from dpc/random_32
Simpler `random_32_bytes`.
2014-08-16 10:23:40 -07:00
Dawid Ciężarkiewicz 1ce6e3fd3b Simpler `random_32_bytes`. 2014-08-16 02:21:35 -07:00
Andrew Poelstra 6c8a72ba5d Remove allocations for Signature, use array instead
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.)
2014-08-15 23:43:40 -07:00
Andrew Poelstra db37829904 Add CC0 license and header to all files 2014-08-11 19:26:45 -07:00
Andrew Poelstra 4be48ecb1b Move Rng failure from `Secp256k1::new` to functions that actually use randomness
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.
2014-08-11 19:24:19 -07:00
Andrew Poelstra d6bf4039bd Pull out initialization code so that `PublicKey::from_secret_key` can be used safely 2014-08-11 19:24:19 -07:00
Andrew Poelstra 522bafe433 Remove VerifyResult since it is never used 2014-08-11 19:24:19 -07:00
Andrew Poelstra 80df78c9a9 Add slice methods to `Nonce` 2014-08-11 19:24:19 -07:00
Andrew Poelstra 0adc7e1ce2 Add keypair slice methods and unit tests 2014-08-11 19:24:19 -07:00
Andrew Poelstra 5b15918a9a Move FFI and constants into their own modules; replace outptrs with returns 2014-08-11 19:24:19 -07:00
Andrew Poelstra 448f4829e7 Move FFI functions into separate module; add documentation and style lints 2014-08-11 19:24:19 -07:00
Dawid Ciężarkiewicz 15e0995585 Add `LICENSE`. 2014-08-10 16:23:40 -07:00
Dawid Ciężarkiewicz 2c2a98a153 Merge pull request #1 from steveklabnik/master
Fix unused imports and add a gitignore
2014-08-04 17:04:33 -07:00
Steve Klabnik 462df41994 Add gitignore 2014-08-04 19:59:58 -04:00
Steve Klabnik 2fa6a4d38e fix unused import warning 2014-08-04 19:58:57 -04:00
Dawid Ciężarkiewicz 100fc277a6 Fix tests cases.
The way compact signatures are working was explain to me:

https://github.com/bitcoin/secp256k1/issues/45
2014-08-04 16:51:47 -07:00
Dawid Ciężarkiewicz 4c9f47e108 Update for newest Cargo 2014-07-23 16:34:04 -07:00
Dawid Ciężarkiewicz 05406515b8 Initial (failing) implementation. 2014-07-06 22:41:22 -07:00