* Replace recompute_R with a separate RCompute
This struct can be use to implement verifiers with incremental updates
* Add raw_sign_byupdate and raw_verify_byupdate
These allow signing/verifying a non-prehashed message
but don't require the whole message to be provided at once.
* Tests for raw_sign_byupdate, raw_verify_byupdate
* Add StreamVerifier
* Make StreamVerifier use RCompute
This allows it to use the same implementation as non-stream signature
verification.
* Guard StreamVerifier behind hazmat feature
* docs: disambiguate unsafety
Co-authored-by: Tony Arcieri <bascule@gmail.com>
* chore: relax F bounds on raw_verify_byupdate
* chore: remove raw_sign_byupdate and raw_verify_byupdate
* chore: address clippy lints within new code
* docs: fixup changelog
* test: invert new chunked test
* chore: revert raw_sign
---------
Co-authored-by: Matt Johnston <matt@ucc.asn.au>
Co-authored-by: Tony Arcieri <bascule@gmail.com>
Removes the previous warning that points are unvalidated: they're
validated using the ZIP-215 rules, which allows unreduced y-coordinates.
Points are ensured valid by performing decompression, which finds a
solution to the curve equation, or returns an error.
Adds references to ZIP-215 and dalek-cryptography/curve25519-dalek#626
which is an issue about potentially adding support for the RFC8032/NIST
validation criteria in the future.
Like #582, there is a new release of `signature` (v2.2.0) which contains
no breaking changes from ed25519-dalek's perspective. The main notable
one is it bumps MSRV to 1.60, which so also happens to also be
ed25519-dalek's MSRV.
This commit loosens the version requirement to allow `>=2.0, <2.3` to
allow the `signature` 2.2 series.
Uses `finish_non_exhaustive` in lieu of printing the `secret_key`
component of a `SigningKey`, only showing the corresponding
`verifying_key` field which can be used to identify the public key.
Closes#591
The `signature` crate contains unstable, minor version-gated
functionality.
The v2.1 release did not change any of that, and only added new
functionality. So it's safe to relax the requirement for `signature` to
`>=2.0, <2.2`.
* ed25519-dalek: remove `ExpandedSecretKey::to_bytes`
The reason `ExpandedSecretKey` needs a private `scalar_bytes` field is
to retain the canonical scalar bytes as output by SHA-512 during key
expansion so they can be serialized by the `to_bytes` method.
However, `ExpandedSecretKey`s should not be serialized to the wire.
Removing this method allows the private field to be removed, which
allows `ExpandedSecretKey` to be constructed entirely from public
fields. This provides an alternative to #544 for use cases like
Ed25519-BIP32 where the private scalar is derived rather than clamped
from bytes.
One other change is needed: `to_scalar_bytes` was changed to `to_scalar`
as the canonical scalar bytes are no longer retained, however this has
no impact on its main use case, X25519 Diffie-Hellman exchanges, where
the `Scalar` should NOT be written to the wire anyway.
* Added scalar byte comparison back to ed25519-dalek x25519 test
---------
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
