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.
