Size of the ed25519 secret key

[mirceanis]

I've seen this pattern in a number of places:

• https://www.npmjs.com/package/tweetnacl#naclsignkeypair
• https://nacl.cr.yp.to/
• libsodium

When a secretKey is generated (which for ed25519 would technically be 32 bytes wide) the public key is precomputed and attached to the output, making it 64 bytes wide.
The reason for this seems to be to avoid one scalar multiplication during signing [to compute the public key bytes].(

noble-curves/src/abstract/edwards.ts

Line 443 in 848a1b0

const k = hashDomainToScalar(options.context, R, pointBytes, msg); // R || A || PH(M)

)

I wonder why this is not done in this library as well.

[paulmillr]

1. Having 64-byte keys where only the first 32 bytes (private) are relevant is dumb. Every other elliptic curve uses ONLY the private part.
2. Having the second half a public key introduces a potential issue. It was found here: https://twitter.com/kostascrypto/status/1538351278413058048. Libraries now need to validate whether the second half is actually the valid key, produced from the first half, and not some garbage. So, many libraries were affected, and the issue has been fixed. We have not been affected in the first place, because we always used 32-byte private keys.
3. Having the second half pre-computed can be considered a cache and speed-up, but ONLY if you don't validate it (see 2), so it's useless speed-up
4. FIPS 186-5 section 7.4, the most recent ed25519 standard, mentions private keys should be 32 bytes, not 64.

So, it was a "meh" decision by the libraries to implement 64-byte keys.

[mirceanis]

Makes sense. Thanks for sharing.

I didn't expect validation to be needed since when the key is just the secret part there can't be any validation done. Trust is put on the user to keep their keys intact.
I don't know why that would change when the key would have extra data.

But I understand your reasoning and agree.