Security: ed25519 verification accepts forged signatures

[paulmillr]

Your implementation of ed25519 accepts forged signatures, it's malleable.

To check this, LE-add curve order to a signature $S$ component. Verification would still pass.

It's pretty bad. To fix, switch to a better ed25519 library.

This issue was first reported 6 months ago.

[vikinatora]

Hey @paulmillr, we're looking for an alternative library that would resolve this issue. We tried using your library@1.7.0 but it didn't work out as NEAR uses 64 byte keys(private key + public key concatenated) f.e E8rptqS9XcQ8RL5EHYCYRTFUXfqTasbseQa7CYPoNEBc7gJQoGkaPAe7cLg4doKkZPqbD6tBhFbBLxE1jv3rwek.
You can create your own key pair by:

NEAR_ENV=mainnet near generate-key your-account-name

This creates a json keypair at ~/.near-credentials/mainnet/your-account-name.json. Consequently, when we invoke

const { getPublicKey, sign, verify, getExtendedPublicKey } = ed.sync;
getPublicKey(privKey);

We get the following error: Expected 32 bytes. We're open to suggestions for resolving the issue and migrating to a safer library.

[paulmillr]

paulmillr/noble-curves#33

write your own wrapper than converts into 64 byte keys. it takes 1 line of code. they are invalid and are NOT supported by FIPS 186-5 or relevant RFC.

also use noble-curves, not noble-ed25519