It occurs to me that we could modify the CAcert process of verifiably creating random seeds to make it also scientifically verifiable, after the event. (See last post if this makes no sense.)
Instead of bringing a non-deterministic scheme, each participant could bring a deterministic scheme which is hitherto secret. E.g., instead of me using my laptop's webcam, I could use a Guttenberg copy of Hamlet, which I first declare in the event itself.
Another participant could use Treasure Island, a third could use Cien aņos de soledad.
As nobody knew what each other participate was going to declare, and the honest players amongst did a best-efforts guess on a new statically consistent tome, we can be sure that if there is at least one honest non-conspiring party, then the result is random.
And now verifiable post facto because we know the inputs.
Does this work? Does it meet all the requirements? I'm not sure because I haven't had time to think about it. Thoughts?
Posted by iang at May 19, 2014 10:19 AM | TrackBackCrypto Algorithms that depend on their parameters to be securely random are unsafe from my point of view anyway.
Itīs like DSA that depends on perfect randomness to make sure that it does not leak the private key. This is unsafe. Donīt use it.
A safe crypto algorithm in the non-military sense must not depend on parameters being generated in a safe way.
A military-safe crypto algorithm must be safe only for your own military and unsafe for the adversary. And it must be safe only when used in a very special way that you only know yourself, and it must be unsafe when used by an unknowing adversary.
But I you really need a protocol to define safe random parameters for unsafe algorithms like ECC:
1: Define a way to extract randomness from a publically verifiable historical source. E.g. the stock exchange courses from several different stock exchanges. E.g. Define how to sample the TOP50 stocks of NewYork, London, Vienna, how to encode them exactly, and how to hash them. Preferrably in useable sourcecode form.
2: Define a certain day in the future (1 week to 1 month) when the samples should be taken
3: Publish the algorithm + specification and timestamp your publication, make sure that all relevant parties have received the publication before the sample-date happens.
4: From the sample-date on everyone can run the provided sourcecode to retrieve the samples and to generate the randomness from it, and everyone should get the same values, and be able to verify that the parameters are not cooked.