# Would key stretching help mitigate concerns with “verifiably random”?

Daniel J. Bernstein (and others) have expressed concern over how "verifiably random" curve parameters are generated. He points out that hashing a public seed doesn't prevent, say, the US government (NIST/NSA) from choosing a seed that produces parameters with a one-in-a-million weakness that is not yet known to the academic community.

If the seed were hashed iteratively instead of just once, would this help address these concerns? If my thinking is correct, iterating a hash function $2^{40}$ times on the seed when producing the standard should make one-in-a-trillion weaknesses mostly infeasible and one-in-a-million weaknesses much more difficult.

• I think it would work, but it would make verification much harder and we don't even know if there's some malicious property behind the choice of parameters. See this related question. – SEJPM May 31 '15 at 19:10

No, not really. The problem is that these kind of parameters may themselves be chosen deliberately. In other words, NIST/NSA may have performed a pre-calculation to make sure that the key stretching outputs a value that opens the algorithm up to some kind of attack.

Lets take an example, would you trust: SHA-256^2^40("Trust me, I'm an innocent string?"). Is that more or less secure than SHA-256^2^40("Trust me, I'm an innocent string"), i.e. without the question mark? How would I know that e.g. NIST or the NSA didn't do a few of these calculations up front to create their preferred output? the amount of iterations may be varied as well.

It's probably easier to secure the input of the hash. If they would say to a group of trusted experts: you all jot down a string, then concatenate them all (ordered by last name), and finally SHA-256 the ASCII string then the output is determined by the aggregated input of the experts.

The Brainpool curves were created in a controlled environment, which makes them more safe - according to DJB - than the NIST curves. Of course this is still less secure as not having to pre-determine any input values. This is the road taken by the highest level safe curves.

• Thanks for the answer. Wouldn't the required pre-calculation be expensive to the point of being impractical? Definitely agreed that having a group of trusted experts (or unrelated parties) is better. – Tim McLean Jun 1 '15 at 18:59
• Note that I originally suggested $2^{40}$ hash iterations, not just $40$. – Tim McLean Jun 1 '15 at 19:00
• Sorry that was what I meant: 2^40. I rewrote it from Tex and this rewriting lost the 2 somehow, leaving just ^40. If the NSA can calculate SHA-256 2^40 times they probably can also handle a 100 times that. I mean 2^47 is not that much higher. It depends on the attack how many candidates need to be calculated. Without knowing the attack we can only hope for a single nothing-up-my-sleeve number. And hope that the entire algorithm is not broken of course. – Maarten Bodewes Jun 1 '15 at 20:07
• Ah, OK. Right, so this would prevent one-in-a-trillion weaknesses, but it wouldn't prevent one-in-a-thousand weaknesses, which are still a concern? – Tim McLean Jun 1 '15 at 20:08
• Yeah, that's about the gist of it. In the end a work factor like this is only a constant in a linear equation - a very large one, but in the end the big O doesn't change. – Maarten Bodewes Jun 1 '15 at 20:09