The only place we discuss directly using Curve25519 is in straightforward DH, as with X25519.

There is more distinguishing Ed25519 from Deterministic ECDSA than deterministic nonce generation.

You suggest using Ed25519 which is vulnerable to third party signature malleability as its cofactor is 8 and the library doesn’t check that the signature is actually a point in the curve.

On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.

That's fair: we don't alert users that these recommendations aren't adequate for building elaborate new signature schemes. We're assuming people are trying to solve the basic problems described in the use cases we wrote (remember, this document originates as a response to a similar thing Colin Percival wrote a long time ago).

I'll think about a way to articulate that. Obviously, we can't really offer advice on doing state-of-the-art signature schemes in a couple paragraphs, and would not be interested in trying.

On the other point: the 2015 version of the document addressed the point you're making (and recommended deterministic DSA!). I just think it's kind of dumb to design new systems with a DSA dependency in 2018, and so rescinded the recommendation.

Could you expand on what's dangerous in using a curve with a non-unit cofactor? I haven't heard of this as an attack vector before.

As a sort of hand-wavy message board explanation: you design a protocol using public-key crypto with the assumption that any given public key pairs with a single private key and with no other public or private keys.

But that's not true: for both Curve25519 and in the Ed25519 signature scheme, which were designed with curves for which point validation is supposedly unnecessary and thus not performed, there are for a given curve point other points --- not valid ones, but ones for which the math will work --- that are equivalent.

For the kinds of things most developers use crypto primitives for, and most of the things everyone was using them for in 2009, these distinctions are --- I'll argue --- not that important. If your transport protocol handshake blows up because of cofactors, the problem probably isn't that you didn't check curve points; it's that you designed a bad key exchange.

But since I don't do cryptocurrency work, like, at all, it's easy to forget that the mainstream of what people do with signature schemes is a lot broader than it was before. I'll try to think of a way to word that and get it into the document.