Initialisation Phase

In the initialisation phase, each trusted peer Pireceives a share xi. For both threshold schemes applied, it required that each trusted peer has a unique ID i that serves as the x-value in Shamir’s secret sharing that is applied by these schemes. The peer IDs must be in accordance to the applied scheme, i.e. peer IDs must not be larger than the order of the share generator polynomial. For Threshold BLS the peerIDs must be of order Zq, where q typically is a 160 bit number. For URSA the peer IDs must be of order ZN, where N is typically 1024 bit or larger. Accordingly, when building the trusted peer overlay, the

key space used when Threshold BLS is applied must not be larger then q. In order to ensure that the key space should be distinctively smaller then q, e.g., for a q of 160 bit a key space of 128 bit should be chosen. For URSA these restrictions are not important as typically DHT-key spaces are distinctively smaller than 1024 bit.

For the initial key generation and assignment, both schemes have in common that a group of peers is required that have to collaborate. For this purpose they require knowledge of the group’s peer IDs. For bootstrapping it can be assumed that this group exists; e.g., the application developer provides a group of peers in order to start-up the system. The minimum size of the group depends on the initial threshold tinitalof the accounting scheme.

4.5.2.1 Initialisation Phase with Threshold BLS

Threshold BLS-scheme (Bol03) applies (GJKR99) for a distributed generation of the initial shares xiof the private key x.

The group of peers generating the initial shares xifirst perform a Pedersen-Verifiable Secret Sharing of a random value zi. The algorithm is described in detail in (GJKR99). Using polynomials of degree t − 1 the minimum size of the group of peers is t in order to reconstruct the shares xi.

Each peer Pi selects two random polynomials fi(z) and fi0(z)over Zq of degree t − 1 and computes the shares sij and s0ij for all other peer Pj. Then each Pi distributes these values together with the verification values Cik to all Pj. If there are any complaints two additional broadcasting rounds are required. Each Pican now compute its shares xi and x0iusing xi=

P jsjiand x0i= P js 0 ji. In order to compute the public key y = gx _{mod p each player exposes its y}

i = gxi mod pusing Feldman Verifiable Secret Sharing. Then the public key is computed using y =Q

iyimod p.

In summary, the initialisation phase for Threshold BLS requires two broadcasting rounds. Assuming a modulus p of length rBLS, p = 512bit and an exponent x of length rBLS, q = 160bit (as suggested in (STY07)), the messages in the first round have the size of three times 512 bits (plus message delimiting headers fields of length ldel). In the second broadcasting round each message has to carry a verification value of 512 bits.

Accordingly, the total upload traffic generated during this phase results in: VBLS, init= t(t − 1) · (2rBLS, q+ rBLS, p+ 3ldel) + t(t − 1)(rBLS, p+ ldel)

This is 3,38 kBytes using a threshold of t = 17 and the assumptions in Table 4.6.

Thus, the overall traffic grows with O(t2_{).The upload traffic per peer generated results in:} vBLS, init= (t − 1)(2rBLS, q+ rBLS, p+ 3ldel) + (t − 1)(rBLS, p+ ldel)

This corresponds to 57.38 kBytes.

Thus, the traffic per peer grows linearly with O(t).

In conclusion, the Threshold BLS initialisation is an efficient way to compute a shared secret private key for the token-based accounting scheme.

4.5.2.2 Initialisation Phase with URSA

URSA is based on RSA signatures. Creating a shared RSA key in a distributed way is very costly compared to generating a shared key in BLS. The reason is that RSA requires a secret pair of prime p and q. Boneh and Franklin presented a mechanism to generate a shared RSA key in (BF01).

The distributed RSA key generation according to (BF01) uses four phases. In the first phase, shared q and p are generated using polynomial secret sharing. Also, q and p are tested with trial divisions if they are prime. This requires a broadcasting round by each Pifor distributing the individual qij and pij to all Pj and another broadcasting round to distribute the results of the trial division. This phase is repeated until a q and a p are found that are not divisible by any prime less than some bound B1.

Using the qi and pi from the first phase in the second phase, N is computed using a distributed mechanism that does not reveal knowledge about qi and pi. In order to share qi and pi, each peer Pi again uses polynomial secret sharing. This requires one broadcasting round and another one for sharing the computed Ni.

In phase three, the found N is tested to understand whether or not it is divisible by small primes in the range [B1, B2]for some bound B2. If this test fails the protocol is restarted from phase one. In this phase, first all peers agree on a random value g ∈ Z∗N. Here we assume that one party selects this value in order to avoid another round of polynomial secret sharing. All peers now have to compute a value vi and share it will all other peers in the group. This is another broadcasting round. vi is required for the first test if N is a prime. For the second test (a Fermat test) each peer computes a value ui and shares it with all Pj. This is another broadcasting round.

If the first three phases were successful, in phase four the public exponent is computed in a distributed way, again using a round of polynomial secret sharing and one round of additive secret sharing.

As shown in (ABF+_{99) the generated traffic is not deterministic due to the distributed guessing of} primes. As several broadcasting rounds are used to check if a number is prime, the generated traffic grows exponentially with an increased group size t.

In conclusion, when URSA is used, an application developer should consider generating the system key and the initial set of shares on a trusted server and creating additional shares using the recovery phase.