Specification for ed25519 key format

Specification says that there are 2 ways of keeping ed25519 private key:
old: [private bytes]+[public bytes]x2 and the new one: [private bytes]+[public bytes].
The new way is free from excessive copying of public bytes.
What format should we use if we receive old-way formatted key?
Should we always support both variants?

@stebalien do you happen to know when the switch was made to the new ed25519 encoding? If it’s not being used much in the wild anymore, perhaps we can deprecate the old encoding.

If we do need to support both encodings, I think it’s best to just store the key in the format that you receive it in, and convert as-needed to the new format internally if you have to (e.g. because your crypto lib requires the new encoding). Altering the encoding before storing it would change the peer id hash.

go-libp2p now stores ed25519 keys in the new format but it retains the ability to read both.

Altering the encoding before storing it would change the peer id hash.

The peer ID is derived from the public key so this the private key format shouldn’t matter. The only concern here is interoperability with old nodes.


TL;DR: I’d continue supporting reading old keys but I’d write them in the new format. However, I wouldn’t bother overwriting existing keys (that’ll just cause headaches on downgrade for no good reason).

hah, sorry, I completely misread the question - thanks for clarifying @stebalien