The process to generate these was opaque, so there was some concern that the values might have been backdoored somehow like Dual_EC_DRBG was; we didn't even have confidence that they were generated from a PRNG rather than some other process. Knowing that the values were generated this way makes it much less plausible that there is such a backdoor.

▲

ArcHound 3 hours ago | parent | next [-]

But you can still analyse the behaviour of the values to identify backdoor behaviour rather than insisting on uncovering the exact method od generation.

Just seems to me like that's quite low on the priority list. I guess this result assures some people that the values are good.

	▲	mswphd 5 minutes ago \| parent [-]
		you (mostly) can't. In computing, "random" is a property of a process to generate a number, not a property of a number itself. You cannot directly analyze a number to determine it has been randomly generated. There are some caveats here. There are some intrinsic properties of numbers that random numbers satisfy with high probability, e.g. having high kolmogorov complexity. But these are generally very difficult to compute, and I would personally guess you could concoct (probably artificial) scenarios where 1. picking parameters randomly yields a secure construction, but 2. there exists a parameter set with high kolmogorov complexity that is insecure. e.g. "high kolmogorov complexity", while being a property of random numbers, is generally not viewed as nearly as useful as being randomly generated (which is exhibited by saying generator + seed = the particular number, like in this article).

▲

charcircuit 3 hours ago | parent | prev [-]

>like Dual_EC_DRBG was

There is no evidence that it was backdoored.