zecfoundation
/
ed25519-zebra
mirror of https://github.com/ZcashFoundation/ed25519-zebra.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
ed25519-zebra/Cargo.toml

51 lines
1.2 KiB
TOML
Raw Normal View History

Initial commit.
2020-01-22 11:31:27 -08:00
[package]
name = "ed25519-zebra"
Prepare 0.1.0 release.
2020-01-24 13:01:41 -08:00
# Before publishing:
# - update CHANGELOG.md
v3.1.0
2022-10-19 07:24:03 -07:00
version = "3.1.0"
Initial commit.
2020-01-22 11:31:27 -08:00
authors = ["Henry de Valence <hdevalence@hdevalence.ca>"]
Stub out the API, based on redjubjub.
2020-01-22 14:57:26 -08:00
license = "MIT OR Apache-2.0"
Initial commit.
2020-01-22 11:31:27 -08:00
edition = "2018"
Stub out the API, based on redjubjub.
2020-01-22 14:57:26 -08:00
repository = "https://github.com/ZcashFoundation/ed25519-zebra"
description = "Zcash-flavored Ed25519 for use in Zebra."
add `no_std` support (#57)
2022-05-05 06:40:29 -07:00
resolver = "2"
Stub out the API, based on redjubjub.
2020-01-22 14:57:26 -08:00
[package.metadata.docs.rs]
Bump version to 0.4.1, fixing docs.rs
2020-06-17 14:28:12 -07:00
features = ["nightly"]
Initial commit.
2020-01-22 11:31:27 -08:00
[dependencies]
update curve25519-dalek to 4.0.0-pre.5; sha2 to 0.10
2023-01-16 10:32:43 -08:00
# "digest" is exempt from SemVer, so we should always use a specific version
curve25519-dalek = { version = "=4.0.0-pre.5", default-features = false, features = ["alloc", "digest"] }
add `no_std` support (#57)
2022-05-05 06:40:29 -07:00
hashbrown = "0.12.0"
Zeroize full signingkey (#73) * Zeroize full signingkey Includes Default and DefaultIsZeroes impl for VerificationKey. Resolves #72 * derive Zeroize for SigningKey
2023-03-15 07:04:32 -07:00
hex = { version = "0.4", default-features = false, features = ["alloc"] }
rand_core = "0.6"
serde = { version = "1", optional = true, features = ["derive"] }
sha2 = { version = "0.10", default-features = false }
zeroize = { version = "1.5", features = [ "zeroize_derive" ] }
Stub out the API, based on redjubjub.
2020-01-22 14:57:26 -08:00
Implement sign, verify.
2020-01-22 16:58:18 -08:00
[dev-dependencies]
Update rand_core to 0.6 and rand to 0.8
2021-03-25 18:41:22 -07:00
rand = "0.8"
Add test vectors from RFC8032.
2020-01-23 17:13:48 -08:00
bincode = "1"
Add benchmarks verifying batch performance estimates. In fact the speedup can be slightly greater than the 2x predicted, because although the multiexp is half the size, the remaining half has 128-bit scalars instead of 256-bit ones.
2020-01-28 21:36:48 -08:00
criterion = "0.3"
Release 2.0.0
2020-07-06 19:43:29 -07:00
ed25519-zebra-legacy = { package = "ed25519-zebra", version = "1" }
Update color-eyre requirement from 0.5 to 0.6 Updates the requirements on [color-eyre](https://github.com/yaahc/color-eyre) to permit the latest version. - [Release notes](https://github.com/yaahc/color-eyre/releases) - [Changelog](https://github.com/yaahc/color-eyre/blob/master/CHANGELOG.md) - [Commits](https://github.com/yaahc/color-eyre/compare/v0.5.2...v0.6.0) --- updated-dependencies: - dependency-name: color-eyre dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
2022-01-12 21:01:54 -08:00
color-eyre = "0.6"
Implement ZIP 215 validation rules. (#24) * Implement ZIP 215 validation rules. These have the effect that batched and singleton verification are now equivalent. * Add ZIP 215 conformance tests. This test constructs signatures on the message "Zcash" using small-order verification keys, some with canonical and some with non-canonical encodings of points. All of these signatures should pass verification under the ZIP 215 rules, but most of them should fail verification under legacy rules. These tests exercise all of the special-case behaviors from the specific version of libsodium used by Zcashd: * the all-zero check for the verification key; * the excluded point encodings for the signature's R value; * the choice to test equality of the encoded bytes of the recomputed R value rather than on the projective coordinates of the two points. Running ``` cargo test -- --nocapture ``` will print a hex-formatted list of the test cases, which can also be found here: https://gist.github.com/hdevalence/93ed42d17ecab8e42138b213812c8cc7 * Update spec links. Thanks to @ebfull for pointing this out. * No ... there is another. @ebfull pointed out that two test cases were duplicates. The cause was that I misread the RFC8032 check was checking for the non-canonical encoding of the identity point that NCC Group apparently brought up. Carefully analyzing all the cases instead of assuming reveals there is another non-canonically encoded point (of order 2). * Change formatting of printed test cases.
2020-07-06 19:40:20 -07:00
once_cell = "1.4"
Implement sign, verify.
2020-01-22 16:58:18 -08:00
Stub out the API, based on redjubjub.
2020-01-22 14:57:26 -08:00
[features]
nightly = []
add `no_std` support (#57)
2022-05-05 06:40:29 -07:00
default = ["serde", "std"]
std = []
Initial implementation of futures-based batch verification. This commit incidentally includes an optimization for batch verification that improves performance when verifying multiple signatures from the same public key. I'm not totally happy with a few things about this API, however. Currently, the actual batch computation is performed only when the inherent `finalize()` method is called on the service. However, this doesn't work well with `tower` layering, because once the service is wrapped, the inherent method is no longer available. Another option would be for the batching service to be created with a batch size parameter, automatically resolving the batch computation whenever the batch size was reached. This improves latency but does not solve the problem of finalizing the batch, since unless there's guaranteed to be a constant stream of verification requests, a tail of requests may be left unresolved. A third option would be for the service to return some kind of control handle on creation that would allow shutdown via a channel or something, but this is also unsatisfying because it means that the service has to be listening for a shutdown signal. A fourth option would be to have a batch size parameter but customize the `Drop` impl to finalize all pending requests on drop; this would potentially allow "flushing" pending requests by manually dropping the service in a way that would still be possible when using tower wrappers.
2020-01-28 17:11:43 -08:00
[[test]]
name = "rfc8032"
[[test]]
name = "unit_tests"
[[test]]
name = "batch"
Add benchmarks verifying batch performance estimates. In fact the speedup can be slightly greater than the 2x predicted, because although the multiexp is half the size, the remaining half has 128-bit scalars instead of 256-bit ones.
2020-01-28 21:36:48 -08:00
[[bench]]
name = "bench"
harness = false