Commit graph

8 commits

Author SHA1 Message Date
pinkforest(she/her)
19c7f4a5d5
Fix new nightly redundant import lint warns (#638) 2024-02-29 18:56:52 -07:00
Jack Lloyd
17eab3d6c1
ed: Make it possible to convert between VerifyingKey and EdwardsPoint (#624)
Adds VerifyingKey::to_edwards and a From conversion

See #623
2024-02-12 14:36:43 -05:00
Pioua
0b45e00ad5
chore: typo fix (#608) 2023-12-13 08:10:05 -07:00
Michael Rosenberg
04f811ad21
ed: Add back SigningKey::to_scalar_bytes (#599)
* Brought back SigningKey::to_scalar_bytes; added regression test

* Updated SigningKey::to_scalar docs and tests
2023-11-14 13:23:48 -05:00
Rob Ede
b93ace8c7f
Address Clippy lints (#543) 2023-08-27 12:47:12 -06:00
Tony Arcieri
20d1346841
Fix CI failures (#548)
There are various small CI failures that are addressed in this PR.
2023-07-22 12:13:10 -04:00
Tony Arcieri
5f0d41fcec
ed25519-dalek: remove ExpandedSecretKey::to_bytes (#545)
* 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>
2023-07-10 22:09:40 -04:00
pinkforest
d62def9c22
Workspace ed25519 under ed25519-dalek 2023-06-27 04:04:09 +00:00