[148134] in cryptography@c2.net mail archive
[Cryptography] Secure random mixing
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Tue Nov 12 15:28:42 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 12 Nov 2013 15:18:58 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1694556808281042823==
Content-Type: multipart/alternative; boundary=001a11c327b6f93a7904eb008ede
--001a11c327b6f93a7904eb008ede
Content-Type: text/plain; charset=ISO-8859-1
Along the way someone suggested
R1(t) | R2(t) | R3(t)
As a randomness function that prevents bias. But actually it does not since
it allows any of the parties to control the output provided that they are
the last to vote. This is a better approach:
H(R1(t) + R2(t) + R3(t))
There is always going to be a byzantine generals issue here. What you need
to avoid that is to have the parties commit to a value before the other
parties reveal their value.
So a better protocol would be to construct the beacon as a Lamport hash
chain and reveal the previous value on each tick. We can now eliminate the
possibility of collusion as the beacon is committed to its value before the
other parties.
The only way to cause a default is if there is a three way collusion and
the beacon provider reveals the source value in advance.
This does sound to me like a function that NIST and its equivalents in
other countries could usefully provide. It would be a 'starter function'
for a state cryptographic bureau (along with a signed time function).
I would imagine the following functions to be potentially useful:
1) A year chain with a time increment of minutes
2) A ten year chain with a time increment of hours
3) A hundred year chain with a time increment of days
A new chain would be started each month for 1, each year for 2 and each
decade for 3 so that there is overlap.
This is a pretty modest outlay. The biggest CP commitment is for chain 1
which is only half a million operations.
The providers could sign all the overlapping chains at the same time as
there are at most 32*8 bytes of chain data.
(Thinking about my trust model, chain 2 is probably redundant)
Governments could have fun promoting their domestic provider of trusted
chain.
And I am sure someone has thought of this before, possibly Lamport himself.
--
Website: http://hallambaker.com/
--001a11c327b6f93a7904eb008ede
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Along the way someone suggested<div><br></div><div>R1(t) |=
R2(t) | R3(t)</div><div><br></div><div>As a randomness function that preve=
nts bias. But actually it does not since it allows any of the parties to co=
ntrol the output provided that they are the last to vote. This is a better =
approach:</div>
<div><br></div><div>H(R1(t) + R2(t) + R3(t))</div><div><br></div><div><br><=
/div><div>There is always going to be a byzantine generals issue here. What=
you need to avoid that is to have the parties commit to a value before the=
other parties reveal their value.=A0</div>
<div><br></div><div>So a better protocol would be to construct the beacon a=
s a Lamport hash chain and reveal the previous value on each tick. We can n=
ow eliminate the possibility of collusion as the beacon is committed to its=
value before the other parties.</div>
<div><br></div><div>The only way to cause a default is if there is a three =
way collusion and the beacon provider reveals the source value in advance.<=
/div><div><br></div><div><br></div><div>This does sound to me like a functi=
on that NIST and its equivalents in other countries could usefully provide.=
It would be a 'starter function' for a state cryptographic bureau =
(along with a signed time function).</div>
<div><br></div><div>I would imagine the following functions to be potential=
ly useful:</div><div><br></div><div>1) A year chain with a time increment o=
f minutes</div><div>2) A ten year chain with a time increment of hours</div=
>
<div>3) A hundred year chain with a time increment of days</div><div><br></=
div><div>A new chain would be started each month for 1, each year for 2 and=
each decade for 3 so that there is overlap.</div><div><br></div><div>This =
is a pretty modest outlay. The biggest CP commitment is for chain 1 which i=
s only half a million operations.</div>
<div><br></div><div>The providers could sign all the overlapping chains at =
the same time as there are at most 32*8 bytes of chain data.</div><div><br>=
</div><div>(Thinking about my trust model, chain 2 is probably redundant)</=
div>
<div><br></div><div><br></div><div>Governments could have fun promoting the=
ir domestic provider of trusted chain.=A0</div><div><br></div><div>And I am=
sure someone has thought of this before, possibly Lamport himself.=A0</div=
>
<div><br></div><div><div><br></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c327b6f93a7904eb008ede--
--===============1694556808281042823==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============1694556808281042823==--
