You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've had many requests to leverage `ed25519-dalek`'s
`ExpandedSecretKey` functionality in order to support keys exported from
YubiHSMs. See #978, #891, and #742.
I have been a bit wary of the implementation though, because it has
always involved having both `ed25519-consensus` and `ed25519-dalek`,
often with enums over multiple key types, which seems incredibly
overcomplicated just to implement this feature.
We originally switched to `ed25519-consensus` because `tendermint-rs`
did, and it makes sense there where ZIP-215 provides consensus-critical
signature verification rules that don't diverge between implementations.
However that's a bit irrelevant for our purposes as this is a signing
service, and ZIP-215 allows us to use whatever signing implementation we
want.
Now that we've vendored `tendermint-p2p` as `tmkms-p2p` we can
unilaterally switch the Ed25519 implementation (back) to
`ed25519-dalek`, which should make adding `ExpandedSecretKey` support
much easier and avoid having to worry about two implementations.
This additionally switches (back) to upstream `curve25519-dalek` so as
to support X25519 as part of the SecretConnection protocol.
0 commit comments