There was a vulnerability reported[0] in zeroize which is patches with
versions >=1.2.0. This patch sets the bound to "1.2" in the Cargo.toml.
[0]: https://rustsec.org/advisories/RUSTSEC-2021-0115
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
* Add JNI code for ed25519-zebra
Add some code allowing other languages, via JNI, to interact with ed25519-zebra. The initial commit:
- Allows users to obtain a random 32 byte signing key seed.
- Allows users to obtain a 32 byte verification key from a signing key seed.
- Allows users to sign arbitrary data.
- Allows users to verify an Ed25519 signature.
- Includes a Java file that can be used.
- Includes some Scala-based JNI tests.
* Review fixups
- Minor Rust code optimizations.
- Rust build optimizations.
- Tweak the JNI JAR prereq script to match the new outputs.
* Significant cleanup
- More build system tidying. The primary goal is to try to firewall the JNI code from everything else.
- README tidying.
* Grab bag of improvements
- Clean up the wrapper classes (streamlining, make constructors private, more mutability safety).
- private -> public for a static variable intended for public usage.
- Minor comment & build system cleanup.
* Bump JNI version to 0.0.4-DEV
Decided to bump the version to reflect earlier changes.
* Hard-code the ed25519-zebra version for ed25519jni to use
* Unify ed25519 JNI version
Also add "-JNI" to assist with tagging and otherwise distinguish the JNI code from the main library version/code.
* Add code to make VerificationKeyBytes comparison easier
Also add a test suite for VerificationKeyBytes.
* VerificationKeyBytes cleanup
- Fix hashCode() override.
- Add a test.
- Remove unneecessary semicolons.
* Add Signature to JNI
Mirror the Signature struct from Rust and add some basic tests. Also do a bit of Scala test cleanup.
* Add batch::Item::verify_single and Item: Clone + Debug.
This closes a gap in the API where it was impossible to retry items in a failed
batch, because the opaque Item type could not be verified individually.
* 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.
It's essential to be able to separate the lifetime of the batch item from the
lifetime of associated data (in this case, the message). The previous API did
this mixed in to the Tower implementation, but it was removed along with that
code.
Making the `queue` function take `I: Into<Item>` means that users who don't
care about lifetimes just need to wrap the function arguments in an extra
tuple.
These are better names than secret and public keys, because they concisely
describe the functional *role* of the key material, not just whether or not the
key is revealed.
The futures-based batch verification design is still good, but it turns out
that things like the latency bounds and control of when to flush the batch
should be common across different kinds of batchable verification. This should
be done by the forthcoming `tower-batch` middleware currently in the Zebra
repo.
Deirdre Connolly
Conrado Gouvea
Christian Poveda
dependabot[bot]
Jose Daniel Hernandez
Fintan Halpenny
José Daniel Hernández
Deirdre Connolly
Douglas Roark
Kim Altintop
Dimitris Apostolou
Henry de Valence
Alexis Sellier