[Protocol] Initiating/coordinating the Summoning phase

[arjunhassard]

A) Seed Distribution 1) Who/what distributes the seed to the participating nodes? 2) Does the seed need to be verifiably random?

• No. It's better if it's not reused/repeated, but it can be sequential (and therefore predictable).
• May be a problem if an attacker compromises a node (e.g. the distributor?) 3) Does the seed value need to be validated by consensus?
• Yes, so the clique is coordinated around the same value.

B) Shared inputs (share indices) 1) Do they have to be secret, like they are in Umbral?

• No, nodes look them up via label.
• They do need to be agreed upon by all members of the clique

C) Aggregating the KFragSlivers 1) Can this happen later, at the point that they are actually used (i.e. the Grant phase)?

• This ensures that all the participating nodes' signatures are preserved, such that they can be verified via consensus or by some other agent. 2) Maybe Enrico can check that all the KFragSlivers were used?
• No, because Enrico is disconnected from grant. Grant can occur before Enrico is involved, or way after. 3) Aggregator Attack: whoever is tasked with aggregating the KFragSlivers can generate KFrags that appear to be pursuant to the policy/SC, but since they are locally encrypted before being sent to Ursulas, it's not easy to verify this. Hence a malicious actor can produce KFrags allowing them to unilaterally control AbioticAlice. Note that nube not being thresholdable is orthogonal to this attack.
• We need a check that the entire clique's KFragSlivers were involved in the aggregation. One component of this: listing the participating nodes in a SC, and verifiable consensus on the membership of each clique. Listed nodes are expected(?) to report for duty.
• May need to ask Bob to check if his retrieval corresponded to the expected set of signatures from the correct clique that produced the KFragSlivers – i.e. some kind of (aggregatable) signature on the CFrag.
• This protocol will have to be different from Umbral anyway because the curve is different (k256 vs bls). Note only the former is verifiable via Ethereum.

[arjunhassard]

Comparing two versions of DKGPRE, where the sensitive material is held by a (a) highly available semi-trusted 5-of-5, or (b) a larger clique that is arguably more collusion-resistant but has greater brick likelihood There's a similar but non-uniform risk with respect to the setup/summoning. How does this differ for (a) and (b)?

[jMyles]

Such a good question, @arjunhassard.