On Mon, Nov 13, 2017 at 08:26:04PM -0700, Sean Bowe wrote: > > Q: What exactly happens if one participant fails to destroy that secret > > and/or > > inputs a low-entropy secret? What about N participants? > > > > The paper states that "We show that security holds even if an adversary has > > limited influence on the beacon." but it's unclear what exactly "limited > > influence" means. > > My understanding was that we lose N bits of security when an attacker > can influence N bits of the randomness beacon.
Oh, I might have misunderstood the paper then: when it says "Random beacon" it really does mean an external random beacon such as the NIST Randomness Beacon, not something generated within the ceremony itself? > This MPC is of the "only one has to be honest" kind. It is irrelevant > if N-1 of the participants have low entropy / known secrets, so long > as just one has high entropy w.r.t. the security parameter. Right > > As N increases you open up a new exfiltration route: the unused N-1 > > responses > > could themselves be the exfiltration route, and thus need to be > > deterministically verified against the N-1 unused secrets. This isn't > > particularly user-friendly, and it's easy to imagine how this could be > > skipped. > > Note that the compute process prints out a hash of the response file, > and so we can "cut-and-choose" in the same way to guard against these > exfiltration routes. As an example, if we use DVDs, we can burn N > response files and note each's respective hash and entropy. Then, > reveal N-1's hash/entropy, but destroy those N-1 DVDs. But note here how there's more opportunities to leak data because the secrets(1) associated with each DVD are simultaneously available to the attacker. OTOH, by simply doing each round separately the code is both simpler, and the attacker has access to less information as only one secret should be available to them at a time. 1) Entropy is an *implementation* of a secret; entropy itself isn't enough. > > Finally, it's interesting how there's a whole class of "sham" participant > >strategies, where someone who runs the computation and uploads an audit > >response w/ revealed secret, but does not actually participate in that round, > >still frustrates attackers who can not tell in advance if that particular > >participant will or will not actually participate. This suggests that the > >current round's challenge should be made public. > > That's very interesting. Right now the transcript is public and so the > current challenge can be computed by anyone, but it would be a little > better if I put the "current" challenge file up for download. Publishing a link on this mailing list would work well. Secondly, as we'll have to archive all this stuff anyway, I'd suggest using the Internet Archive for distribution of the challenges. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
