166 lines
8.6 KiB
HTML
166 lines
8.6 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [zapps-wg] Randomness Beacon
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="/pipermail/zapps-wg/2018/index.html" >
|
|
<LINK REL="made" HREF="mailto:zapps-wg%40lists.zfnd.org?Subject=Re%3A%20%5Bzapps-wg%5D%20Randomness%20Beacon&In-Reply-To=%3C6d940698-f1f8-d06c-ea0b-43e0c343f8a2%40gmail.com%3E">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
<style type="text/css">
|
|
pre {
|
|
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
|
|
}
|
|
</style>
|
|
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
<LINK REL="Previous" HREF="000265.html">
|
|
<LINK REL="Next" HREF="000267.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[zapps-wg] Randomness Beacon</H1>
|
|
<B>Kevin</B>
|
|
<A HREF="mailto:zapps-wg%40lists.zfnd.org?Subject=Re%3A%20%5Bzapps-wg%5D%20Randomness%20Beacon&In-Reply-To=%3C6d940698-f1f8-d06c-ea0b-43e0c343f8a2%40gmail.com%3E"
|
|
TITLE="[zapps-wg] Randomness Beacon">kevinsisco61784 at gmail.com
|
|
</A><BR>
|
|
<I>Fri Feb 16 11:41:00 EST 2018</I>
|
|
<P><UL>
|
|
<LI>Previous message (by thread): <A HREF="000265.html">[zapps-wg] Randomness Beacon
|
|
</A></li>
|
|
<LI>Next message (by thread): <A HREF="000267.html">[zapps-wg] Randomness Beacon
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#266">[ date ]</a>
|
|
<a href="thread.html#266">[ thread ]</a>
|
|
<a href="subject.html#266">[ subject ]</a>
|
|
<a href="author.html#266">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>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:
|
|
><i> In order to reduce the probability of a powerful adversary influencing the
|
|
</I>><i> beacon, I would propose to use several sources of entropy, mixing them
|
|
</I>><i> together (maybe concatenating and hashing) and use the result as a seed for a
|
|
</I>><i> PRNG. The mentioned bitcoin block could be one of those sources, but we can
|
|
</I>><i> also add more. Some ideas:
|
|
</I>><i>
|
|
</I>><i> - Results of sports competitions (i.e.: we commit to use the results of the
|
|
</I>><i> NBA playoffs, or something like that)
|
|
</I>><i> - Values of several stock markets at a given future date.
|
|
</I>><i> - Some meteorological information, like "the maximum temperature reached in
|
|
</I>><i> these cities in this given future date, as given by the official daily report of
|
|
</I>><i> these organizations.
|
|
</I>><i> - Some astronomical phenomena: things like solar activity at a given future
|
|
</I>><i> instant (again, as reported by a specific set of observatories that regularly
|
|
</I>><i> reports those things), radiation of a specific pulsar...
|
|
</I>><i> - number of births/deaths/marriages... in a given set of countries/cities/
|
|
</I>><i> whatever (as reported by the corresponding institutions...)
|
|
</I>><i>
|
|
</I>><i> Of course, we need to be very specific in advance about how these pieces of
|
|
</I>><i> information will be collected and represented. But once done that, each one of
|
|
</I>><i> them would add extra entropy. That way, an adversary that wants to predict or
|
|
</I>><i> influence the result of the beacon, would need a huge social power to
|
|
</I>><i> manipulate both sport competitions, stock markets, scientific institutions,
|
|
</I>><i> statistical services... And even then, the meteorological/astronomical reports
|
|
</I>><i> could only be manipulated to a limited extent (it would be too evident if the
|
|
</I>><i> maximum reported temperature differs more than a few degrees to the one that
|
|
</I>><i> people actually experienced in that place).
|
|
</I>><i>
|
|
</I>><i>
|
|
</I>><i> El viernes, 16 de febrero de 2018 0:37:05 (CET) Sean Bowe via zapps-wg
|
|
</I>><i> escribió:
|
|
</I>>><i> The Powers of Tau security proof (see
|
|
</I>>><i> <A HREF="https://eprint.iacr.org/2017/1050">https://eprint.iacr.org/2017/1050</A>) holds in the "random beacon model,"
|
|
</I>>><i> meaning that we must apply a random beacon at the end of the ceremony.
|
|
</I>>><i> It's not good enough to use (say) a hash of the transcript, because of
|
|
</I>>><i> adaptive attacks (the last participant could predict the beacon
|
|
</I>>><i> output). We must apply a beacon that is queried after the ceremony has
|
|
</I>>><i> completed.
|
|
</I>>><i>
|
|
</I>>><i> There is some good news on this front:
|
|
</I>>><i>
|
|
</I>>><i> 1. We *can* query reasonably secure beacons. More on that later.
|
|
</I>>><i> 2. Even if the beacon is partially controlled by an adversary, we only
|
|
</I>>><i> lose a bit of security for every bit of the beacon output that is
|
|
</I>>><i> influenced by the adversary. This means our beacon could be somewhat
|
|
</I>>><i> broken and we'll live in acceptable security bounds.
|
|
</I>>><i> 3. Even if the beacon is _totally_ insecure, it may not even matter
|
|
</I>>><i> because we may be able to prove the MPC is secure using the same
|
|
</I>>><i> assumptions the proving system itself uses. We haven't had time to
|
|
</I>>><i> write a security proof of this yet.
|
|
</I>>><i> 4. Even if we choose a _totally_ insecure beacon, you can just apply
|
|
</I>>><i> your own beacon instead (one that you're more confident in, or perhaps
|
|
</I>>><i> the result of a random coinflip protocol depending on what you're
|
|
</I>>><i> doing).
|
|
</I>>><i>
|
|
</I>>><i> But, let's choose a pretty good beacon anyway. Some notes on that:
|
|
</I>>><i>
|
|
</I>>><i> * There is a large space of possible choices for a beacon, so it's
|
|
</I>>><i> important that we choose the most obvious and reliable one we can
|
|
</I>>><i> think of.
|
|
</I>>><i> * It's important that we choose when we intend to query it, before we do so.
|
|
</I>>><i> * The result of the beacon (and how the beacon is applied to the
|
|
</I>>><i> parameters, such as what PRNG we use, and the code) needs to be
|
|
</I>>><i> determined before we query the beacon.
|
|
</I>>><i> * Since we could choose multiple beacons (and adaptively select from
|
|
</I>>><i> them) we need to publish our choice of a beacon widely, using
|
|
</I>>><i> signatures and social media, so that proof we had attempted to do so
|
|
</I>>><i> would be easy to find.
|
|
</I>>><i> * Anything else?
|
|
</I>>><i>
|
|
</I>>><i> So, what beacon should we use? I'm borrowing my recommendation from
|
|
</I>>><i> advice given by Joseph Bonneau.
|
|
</I>>><i>
|
|
</I>>><i> I think that we should select a Bitcoin block height (in advance) and
|
|
</I>>><i> iteratively SHA256 the eventual block (hash or header) n times to
|
|
</I>>><i> produce the seed of a ChaCha20 PRNG, which is then used to apply the
|
|
</I>>><i> beacon to the parameters. This iterative function is not intended to
|
|
</I>>><i> be a proof-of-work function but instead a "delay function," so it is
|
|
</I>>><i> deliberately not parallelizable. As the time required for a powerful
|
|
</I>>><i> adversary to compute the delay function grows (with respect to the
|
|
</I>>><i> average time between blocks) we become more and more confident the
|
|
</I>>><i> result could not be significantly influenced.
|
|
</I>>><i>
|
|
</I>>><i> How large should n be? I think n=2^40 would be enough, since even if
|
|
</I>>><i> we're off by a couple orders of magnitude the adversary cannot
|
|
</I>>><i> influence enough bits of the result for it to really matter.
|
|
</I>>><i>
|
|
</I>>><i> Other questions include: How should we choose the block height? Should
|
|
</I>>><i> we hash the header or the block hash or even the whole block?
|
|
</I>>><i>
|
|
</I>>><i> Sean
|
|
</I>
|
|
|
|
---
|
|
This email has been checked for viruses by Avast antivirus software.
|
|
<A HREF="https://www.avast.com/antivirus">https://www.avast.com/antivirus</A>
|
|
|
|
|
|
</PRE>
|
|
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI>Previous message (by thread): <A HREF="000265.html">[zapps-wg] Randomness Beacon
|
|
</A></li>
|
|
<LI>Next message (by thread): <A HREF="000267.html">[zapps-wg] Randomness Beacon
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#266">[ date ]</a>
|
|
<a href="thread.html#266">[ thread ]</a>
|
|
<a href="subject.html#266">[ subject ]</a>
|
|
<a href="author.html#266">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
|
|
<hr>
|
|
<a href="/mailman/listinfo/zapps-wg">More information about the zapps-wg
|
|
mailing list</a><br>
|
|
</body></html>
|