MalformedPublicKey CometBFT v0.38.2

[N0lanV]

Hello,

I apologize in advance if the error is on my side or if it's an expected behavior.

When I try to parse the verification key received from a CometBFT 0.38.2, sometimes the TryFrom return an Error MalformedPublicKey.

Example => [4, 134, 169, 60, 181, 144, 128, 181, 142, 35, 187, 61, 60, 63, 216, 121, 140, 238, 127, 11, 129, 219, 53, 219, 180, 139, 155, 51, 41, 190, 138, 91]

[N0lanV]

I think I understand.

Your library uses ZIP-215 which, if I understand correctly, is based on RFC-8032 but with a few additions.

And CometBFT uses the standard Go library which follows RFC-7748. This explains why some of the keys I receive are invalid.

What misled me was that the CometBFT specification says that Tendermint adopted ZIP-215.

I'm not a mathemagician so I may be completely wrong.

I will use the x25519_dalek until ComeBFT follow the ZIP-215.

[hdevalence]

@d-banana That seems like a regression in CometBFT, reopening the issue and will ask upstream.

[hdevalence]

@d-banana Where did you get that public key from? You said it was returned by CometBFT, what was it returned from specifically?

[N0lanV]

@hdevalence From a local node using a fork version of CometBFT used by DYDX (I've checked that they haven't modified this part of the code ofc). https://github.com/dydxprotocol/cometbft

I simply retrieve the 32 bytes sent by the node when I initiate the tcp_stream and try to convert it to ED25519. https://github.com/d-banana/dydx-chain-stupid-node/blob/310b5256edb0506661b3080347001e3839118430/src/peer/setup.rs#L87

[N0lanV]

The Node persistent key is generated(if not provided) by the OasisProtocol implementation which follow the ZIP-215. cometbft/p2p/key.go

..
privKey := ed25519.GenPrivKey()
..

cometbft/crypto/ed25519/ed25519.go

..
verifyOptions = &ed25519.Options{
        Verify: ed25519.VerifyOptionsZIP_215,
    }
...

But the Ephemeral key used the Go implementation with RFC-7748 cometbft/p2p/conn/secret_connection.go

..
ephPub, ephPriv, err = box.GenerateKey(crand.Reader)
..

golang/crypto/curve25519/curve25519.go

..
// Package curve25519 provides an implementation of the X25519 function, which
// performs scalar multiplication on the elliptic curve known as Curve25519.
// See RFC 7748.
..

[hdevalence]

It seems like the problem might be that the CometBFT transport layer is using X25519 keys, not Ed25519 keys. X25519 keys are different from Ed25519 keys, the key agreement mechanism in X25519 is designed so that there isn't any validation required on secret and public keys. This library won't work for those keys, it only does signing, not key agreement, so using x25519 would be the way to go.

[N0lanV]

Ok thanks for your time ! I close this issue ;)