search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

Add test vectors for encoding and decoding keypairs #533

Closed thomaseizinger closed 1 year ago

thomaseizinger commented 1 year ago

We support encoding and decoding keys in various formats but there is not standardized test-suite that implementations can test against.

We should fix that by providing at least one test vector for each key type.

marten-seemann commented 1 year ago

Sounds reasonable. Want to send a PR? Happy to do a cross-check with go-libp2p.

thomaseizinger commented 1 year ago

What would be the best way here?

We can provide hex-encoded, serialised protobuf for each private key and public key. That covers the decoding bit. Is there any way we can cover the encoding bit?

marten-seemann commented 1 year ago

Why does this not cover the encoding part, if we also provide the hex-encoded private key?

thomaseizinger commented 1 year ago

Why does this not cover the encoding part, if we also provide the hex-encoded private key?

Because technically, that is extending the spec that we should also support decoding a private key from hex of some secret which is again a different format for each key type.

The crypto library we use for RSA for example doesn't even allow us to initalise a private key from just the secret exponent (for security reasons I presume). I can imagine other languages have similar restrictions.

I guess what we could do is tell implementations to add a decode-encode roundtrip test. That, together with some tests for verifying signatures should make sure the key is parsed correctly and can also be encoded again.