As someone who has contributed to the Randomness Beacon project, I need
to point out that it is not cryptographicly secure on it's own. Mixing
entropy is a good idea.
On 2/16/2018 11:33 AM, mmarco--- via zapps-wg wrote:
In order to reduce the probability of a powerful adversary influencing the
beacon, I would propose to use several sources of entropy, mixing them
together (maybe concatenating and hashing) and use the result as a seed for a
PRNG. The mentioned bitcoin block could be one of those sources, but we can
also add more. Some ideas:
- Results of sports competitions (i.e.: we commit to use the results of the
NBA playoffs, or something like that)
- Values of several stock markets at a given future date.
- Some meteorological information, like "the maximum temperature reached in
these cities in this given future date, as given by the official daily report of
these organizations.
- Some astronomical phenomena: things like solar activity at a given future
instant (again, as reported by a specific set of observatories that regularly
reports those things), radiation of a specific pulsar...
- number of births/deaths/marriages... in a given set of countries/cities/
whatever (as reported by the corresponding institutions...)
Of course, we need to be very specific in advance about how these pieces of
information will be collected and represented. But once done that, each one of
them would add extra entropy. That way, an adversary that wants to predict or
influence the result of the beacon, would need a huge social power to
manipulate both sport competitions, stock markets, scientific institutions,
statistical services... And even then, the meteorological/astronomical reports
could only be manipulated to a limited extent (it would be too evident if the
maximum reported temperature differs more than a few degrees to the one that
people actually experienced in that place).
El viernes, 16 de febrero de 2018 0:37:05 (CET) Sean Bowe via zapps-wg
escribió:
The Powers of Tau security proof (see
https://eprint.iacr.org/2017/1050) holds in the "random beacon model,"
meaning that we must apply a random beacon at the end of the ceremony.
It's not good enough to use (say) a hash of the transcript, because of
adaptive attacks (the last participant could predict the beacon
output). We must apply a beacon that is queried after the ceremony has
completed.
There is some good news on this front:
1. We *can* query reasonably secure beacons. More on that later.
2. Even if the beacon is partially controlled by an adversary, we only
lose a bit of security for every bit of the beacon output that is
influenced by the adversary. This means our beacon could be somewhat
broken and we'll live in acceptable security bounds.
3. Even if the beacon is _totally_ insecure, it may not even matter
because we may be able to prove the MPC is secure using the same
assumptions the proving system itself uses. We haven't had time to
write a security proof of this yet.
4. Even if we choose a _totally_ insecure beacon, you can just apply
your own beacon instead (one that you're more confident in, or perhaps
the result of a random coinflip protocol depending on what you're
doing).
But, let's choose a pretty good beacon anyway. Some notes on that:
* There is a large space of possible choices for a beacon, so it's
important that we choose the most obvious and reliable one we can
think of.
* It's important that we choose when we intend to query it, before we do so.
* The result of the beacon (and how the beacon is applied to the
parameters, such as what PRNG we use, and the code) needs to be
determined before we query the beacon.
* Since we could choose multiple beacons (and adaptively select from
them) we need to publish our choice of a beacon widely, using
signatures and social media, so that proof we had attempted to do so
would be easy to find.
* Anything else?
So, what beacon should we use? I'm borrowing my recommendation from
advice given by Joseph Bonneau.
I think that we should select a Bitcoin block height (in advance) and
iteratively SHA256 the eventual block (hash or header) n times to
produce the seed of a ChaCha20 PRNG, which is then used to apply the
beacon to the parameters. This iterative function is not intended to
be a proof-of-work function but instead a "delay function," so it is
deliberately not parallelizable. As the time required for a powerful
adversary to compute the delay function grows (with respect to the
average time between blocks) we become more and more confident the
result could not be significantly influenced.
How large should n be? I think n=2^40 would be enough, since even if
we're off by a couple orders of magnitude the adversary cannot
influence enough bits of the result for it to really matter.
Other questions include: How should we choose the block height? Should
we hash the header or the block hash or even the whole block?
Sean
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
