* upgrade curve25519-dalek to 4.0.0-rc.2
* clippy fixes
* activate ed25519/pem only when needed
* bump to 4.0.0; bump MSRV to 1.65; fix no_std support; test MSRV and no_std in CI
* use rust-toolchain instead of TOML to work with (unmaitained) actions-rs/toolchain
* Add DER & PEM support for SigningKeySeed and VerificationKeyBytes (RFC 8410)
- Add encoding to and decoding from DER bytes and PEM strings for SigningKeySeed and VerificationKeyBytes.
- Add some functions so that the Java code mirrors, to a certain degree, the JDK 15 interface for Ed25519 keys and signatures.
- Add encoding and decoding for signatures (technically identity functions).
- Miscellaneous cleanup.
* Accommodate extra octet string in private key DER bytes
- In RFC 8410, DER-encoded private keys are in an octet string that's encapsulated by another octet string. Add the extra octet string, and adjust tests as necessary.
- In the tests, use the private key from RFC 8410, Sect. 10.3.
* Update pkcs8 to 0.7.0
* Cleanup
- Enhance PEM capabilities for SigningKey and VerificationKeyBytes. This also allowed for some tests to be simplified.
- From -> TryFrom for some VerificationKeyBytes impls.
* Upgrade JNI Rust bindings to PKCS8 0.7.5
- Make necessary changes to support the newer crate.
- Fix an unrelated compiler warning.
* More fixups
- Get code to compile after updating to the latest Rust.
- Fix a couple of failing tests (add LF to expected encoding output).
* Major update
- Update pkcs8 crate to 0.10.0, and update code as required to support the crate. This includes supporting the Decode(Public/Private)Key and Encode(Public/Private)Key traits so as to take advantage of Ed25519 DER and PEM code in the crate.
- Add the latest ed25519 crate (2.2.0) to support KeypairBytes and other features.
- Remove the signature code and implement Signature (Signer and Verifier traits) from the "signatures" crate included with the pkcs8 crate.
- Update the JNI code. This includes mandating Scala 3 usage.
- Minor cleanup (including warning fixes) and changes to make the code a bit clearer.
A follow-up commit will clean up the tests and probably add support for v2 private DER keys.
* Further code cleanup
- Update pkcs8 crate to 0.10.1.
- Fix PEM feature code.
- Update Ed25519 JNI code as needed.
- Remove dead code.
- Re-enable a couple of unit tests.
Note that a couple of Ed25519 JNI unit tests are still failing. A follow-up PR will have the fix.
* Add missing DER/PEM files for unit tests
* Add JNI comments to resolve publisher warnings
When executing `sbt publishLocal` and generating a JAR file, there are warnings regarding some functions not having public comments. Add public comments as needed.
* JNI README update
* Comment touchup
* Review fixups
- Finish adding PEM/PKCS8 tags and cfg items as needed to separate the features from default compilation.
- Revert some minor name changes.
- Make the JNI README more precise with regards to requirements.
- Add ARM64 macOS support to JNI. Untested but it should work, and it doesn't break Intel Macs.
- Miscellaneous cleanup, including fixing cargo and sbt warnings.
* Upgrade jni crate to 0.20.0
The 0.21.X crates feature a major refactor that breaks the code. Don't upgrade to them until some issues are resolved. (See https://github.com/jni-rs/jni-rs/issues/432 for more info.)
* Upgrade jni crate to 0.21.1
- A path forward to upgrading to 0.21.X was suggested by the jni-rs library developer (https://github.com/jni-rs/jni-rs/issues/439#issuecomment-1493074721). Upgrade the code, improving the safety of the JNI code.
- Cargo.toml fixups.
* cargo clippy / cargo fmt cleanup
Also do minor JNI README cleanup.
* Use an export to clean up some tests a bit
---------
Co-authored-by: Douglas Roark <douglas.roark@gemini.com>
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>
* 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.
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.
This will hopefully allow things like building a Tower layer with a timeout and
a retry policy that retries timed out requests (not a big enough concurrent
batch) with singleton verification, or retries a failed batch by falling back
to singleton verification to detect which element of a batch failed.
However, there are still some rough spots in the API, and it's not clear that
manually dropping the service is an adequate way to flush requests (see comment).
dependabot[bot]
Conrado Gouvea
Conrado Gouvea
pinkforest(she/her)
Vlad Semenov
Douglas Roark
Deirdre Connolly
Christian Poveda
Fintan Halpenny
Deirdre Connolly
Kim Altintop
Henry de Valence
dependabot-preview[bot]