On 09/08/2013 07:08 AM, Eugen Leitl wrote:
Okay, I need to eat my words here.
I went to review the deterministic procedure ...
The deterministic procedure basically computes SHA1 on some seed and
uses it to assign the parameters then checks the curve order, etc..
wash rinse repeat.
Then I looked at the random seed values for the P-xxxr curves. For
example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90.
... The stated purpose of the "veritably random" procedure "ensures
> that the parameters cannot be predetermined ... and no trapdoors can
have been placed in the parameters during their generation".
Considering the stated purpose I would have expected the seed to be
some small value like ... "6F" and for all smaller values to fail the
test. Anything else would have suggested that ... the parameters
could embody any undisclosed mathematical characteristic whose
rareness is only bounded by how many times they could run sha1 and
test.
Eugene has a very strong point. Clearly we need to replace deployed
instances of those curves. And just doing that is going to be a
years-long project that takes hundreds of people and won't be fully
(re)deployed for decades. If then. Can we rerun the code starting
at a more reasonable place and see what curves develop?
Good god, we need to re-evaluate *EVERYTHING* that's deployed in the
last 20 years for safety and security, from the standards level down.
This is critical public infrastructure we're talking about here and
we don't even know how much of it has been sabotaged. By people we
usually trusted, whose mission was to enhance communications security.
Ray
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
