milksad
/
rust-secp256k1-unsafe-fast
14
0
Fork 0
Code Issues Pull Requests Activity
rust-secp256k1-unsafe-fast/Cargo.toml

15 lines
292 B
TOML
Raw Normal View History

Initial (failing) implementation.
2014-07-07 05:41:22 +00:00
[package]
Change name to secp256k1 from bitcoin-secp256k1-rs [breaking-change]
2015-03-25 22:20:44 +00:00
name = "secp256k1"
Revert "Overhaul interface to use zero-on-free SecretKeys" This reverts commit 98890907849326a0e265d0ee12d3caa232b19602. This is not ready for primetime -- the move prevention also prevents reborrowing, which makes secret keys nearly unusable.
2014-09-12 13:28:35 +00:00
version = "0.0.1"
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-09-01 03:26:02 +00:00
authors = [ "Dawid Ciężarkiewicz <dpc@ucore.info>",
"Andrew Poelstra <apoelstra@wpsoftware.net" ]
Initial (failing) implementation.
2014-07-07 05:41:22 +00:00
Add .travis.yml, update tests and Cargo.toml for upstream changes
2014-08-18 01:55:07 +00:00
[lib]
Change name to secp256k1 from bitcoin-secp256k1-rs [breaking-change]
2015-03-25 22:20:44 +00:00
name = "secp256k1"
Update for newest Cargo
2014-07-23 23:11:18 +00:00
path = "src/secp256k1.rs"
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-09-01 03:26:02 +00:00
[dependencies.rust-crypto]
git = "https://github.com/DaGenix/rust-crypto.git"