ECDH curve hard-coded

Line 175 in 3c911e9

ECDH_ALGO_ID = 18

This corresponds to curve25519. Now my primary key uses the nistp256 curve so I can assume this constant had a different value at some point. Would it not be better to give the user the option to use whichever supported curve they wanted namely nistp256 or curve25519? {I don't think ed25519 is a curve so CURVE_ED25519 should not exist.)

(Aside, is it possible to delete one's primary key if they wanted to start afresh and use curve25519 instead?)

The big question is if the hardware supports nistp256 for ECDH, and if it has the same algo id or a different one. If it has the same, my latest PR (plus some adjustments) would probably be necessary for support, since you can no longer identify ECDH vs ECDSA based on the algo alone. If it's a different one, then the appropriate serialization and keygrip protocols would have to be added.

(Aside, is it possible to delete one's primary key if they wanted to start afresh and use curve25519 instead?)

Currently, it's possible by deleting the whole ~/.gnupg/trezor folder. With my latest PR, it can be done without.

OK but the line I quoted is from the generic libagent library so it it defines the ECDH key exchange algorithm used ad hardcodes it. It seems it can either be nistp256 (19), curve25519 (18) or ed25519 (22) though I don't believe ed25519 is a curve but rather a signature algorithm that uses the curve25519 curve. In the same way ecdsa is another signature algorithm but uses the nistp256 curve instead. See also my comment here.

Currently, it's possible by deleting the whole ~/.gnupg/trezor folder. With my latest PR, it can be done without.

OK, good to know.