strange issue with ED25519 keys

[jvsteiner]

I have a test failing in my code (below) and I think it shouldn't. Perhaps I'm missing something though - was wondering if this is a bug, or I have incorrect assumptions somewhere:

func TestPubKey(t *testing.T) {
	priv, _, _ := crypto.GenerateEd25519Key(mrand.New(mrand.NewSource(0)))
	id1, _ := peer.IDFromEd25519PublicKey(priv.GetPublic())
	id2, _ := peer.IDFromPrivateKey(priv)
	assert.Equal(t, id1.Pretty(), id2.Pretty(), "should be equal?") // fails...
}

p.s. I found that IDFromPublicKey works instead of IDFromEd25519PublicKey but the difference still seems strange...

[Stebalien]

My guess is that one inlines the key and the other doesn't. It's imperative that we be consistent here. Otherwise, peers can end up with multiple identities and everything breaks in weird, hard to understand ways.

[jvsteiner]

for my use case, I'm using the public key as an identifier (topic actually) in go-floodsub. therefore I rely on the peer.ID output from IDFromEd25519PublicKey to set the topic, and it's important that I can derive a key that can be used to verify a signature that was created with the corresponding private key, although this output doesn't look like a multiaddr - doesn't start with "Qm" etc.

While it would be nice if that public key string representation were consistent with the part of the multiaddr that indicates the identity, the important thing is being able to derive the public key. Currently, I can't do that with IDFromPublicKey or peer.IDFromString. I wonder if there is a hash function in the way between the multiaddr representation and a usable public key...

[Stebalien]

For RSA keys, there is (RSA public are big). Ed25519 keys are supposed to be inlined. (apparently not)