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
{{ message }}
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.
Have not verified across the key types but at least on Ed25519PrivateKey / Ed25519PublicKey instances .marshal() returns different result from crypto.keys.marshal(key) which is unexpected.
What's worse though that crypto.keys.unmarshalPrivateKey(prk.marshall(), ...) errors.
I would expect that not to be a case.
The text was updated successfully, but these errors were encountered:
.marshal() returns the data that is later wrapped in a protocol buffer that contains the type and the raw data returned from the .marshal() function by .marshalPrivateKey
That output can later be un-wrapped by .unmarshalPrivateKey
tl;dr Don't use .marshal() directly, use the functions from the crypto.keys APIs
Is there some good documentation around about interoperability with go-libp2p-crypto in this respect? I'm seeing that one needs to stick with crypto.keys.marshal*Key and crypto.keys. unmarshal*Key, but even this seems to lead to issues in some cases?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Have not verified across the key types but at least on Ed25519PrivateKey / Ed25519PublicKey instances
.marshal()
returns different result fromcrypto.keys.marshal(key)
which is unexpected.What's worse though that
crypto.keys.unmarshalPrivateKey(prk.marshall(), ...)
errors.I would expect that not to be a case.
The text was updated successfully, but these errors were encountered: