That Daniel j Bernstein let Jacob Applebaum (tor developer and activist) study his PhD under him, despite horrendous accusations, makes me trust Daniel j Bernstein even more. Ppl are crazy to trust an ECC with constraints that are invariable and chosen without "reason" ie P256 and other NIST stuff.
Discussion
"invariable" - meaning what?
unjustified choice of generator - is a fascinating piece of trivia, but is not worrying *in itself* when you take into account random self-reducibility.
On the other hand curve25519 is *not prime order* and that is a *huge* deal in practical security, it has bitten so many people.
DJB is incredible and I agree wholeheartedly about the Applebaum case. But he's not a God. You hear this kind of thing constantly, like people thinking "Bitcoin uses ECDSA, it doesn't have deterministic random nonces, lol, how could you be dumb enough not to use the industry standard Ed25519", just showing complete and utter ignorance of what these protocols actually are, and what Bitcoin is and how it changed over the years (sorry slight tangent but it's illustrative of a very ignorant attitude).
For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90. No justification is given for that value.
There are two points – P1 and P2 on a curve. The first is used to calculate a random value, which is a coordinate x of the production n*P1, where n can be considered as an internal state of the algorithm. P2 is used to change an internal state of the algorithm by calculating the production n*P2 and using its x coordinate as a new state. If there was a dependency between P1 and P2, e.g. if P2 = s*P1, then calculating internal state becomes trivial – it’s an x coordinate of s*P1*n, where both P1*n and ‘s’ are known to an attacker. Since a method of P2 selection has never been disclosed, it created suspicions that a backdoor key has existed and was known to the algorithm creator since day one.
Just one of so many examples.
https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters
Why are you describing the backdoor in DUAL_EC_DRBG, without referencing/naming it?
That's separate. It *is* an issue of NUMS not being used, which is *analogous*, but it's different to the lack of NUMS generation of constants in curves defined by NIST etc.
(The link is certainly relevant though, of course; these details, in case you weren't aware, were already known in the bitcoin world in 2013).
I'm not saying that ppl should trust ed25519 -or any other encryption- but I am saying I wouldn't trust anything that NIST is advocating. Personally I have some reservations about ECC in general. I brought up Duel_EC__DRBG to illustrate how the NSA works. They paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm. NIST is not your friend.