> ECDH doesn't give you authenticity, i.e., you can't get a certificate for that.

ECDH doesn't, but ECDSA does. That's why we have Curve25519 & Ed25519, respectively.

Could you be more specific about the "vulnerable numbers" we're talking about? The curve base point is a parameter for ECDSA as well.

I agree that any protocol that required you to generate curves or even base points on the fly would have similar concerns, but we generally don't use those kinds of protocols.

My err - rubbish wording as I was thinking primes and talking curves.

Still, while I'm punching here a wee bit above my weight - I should read the 186-4 again - there are some tests to verify the strength of the prime. Is it enough for a similar classification? - I don't know...

The prime field is part of the definition of the curve. Everyone interoperating on that curve shares it. It may have been generated weirdly --- the Curve25519 prime sure was! --- but all that tells you is what curve they're using.

It's true that the particular curves a system supports could be a kind of fingerprint, but that's a banal observation, equally true of the ciphers they support, or the compression algorithms.

My last comment was towards key generation, not curves. Bug as I said, I am not in a position to say what the impact is.

Sorry, I don't follow. Are you talking about key generation in ECC systems? There's no prime involved there.