Abstract by anuja a sonalker on Asymmetric Key Distribution

Fig 4.3: The Trusted Dealer’s private key share table after key share generation. 
Lookup 
Index 
S
1
Lookup 
Index 
S
2
Lookup 
Index 
S
t
Lookup 
Index 
S
t+1 
(Special 
Server) 
123 d
1
123 
d
2
123 
- 123 d
c1
124 d
1
124 
- 
124 
- 124 d
c2
: : 
: : 
: : 
: 
: 
345 : 
345 : 
…. 
345 : 
345 : 
Table for S
1 
Table for S
2 
Table for S
t 
Table for S
t+1 
. 
Fig 4.4: Private key share tables of the servers after key distribution. 

---

43 
Each share servers private key share table comprises of two columns, one containing the 
string lookup and the other containing the private key values. The items are indexed 
serially from 0 to 
1
+
−
t
k
C
k
t
-1. Each server has 
1
+
−
t
k
C
k
t
number of sets. Each server 
acknowledges the receipt of his share sets to the Trusted Dealer. Once the private-keys 
are distributed successfully, the Trusted Dealer sends an OK signal to the Special Server. 
The servers are now ready for transactions. 
Though anyone can start a Certificate Signing Request (CSR), in this implementation the 
Special Server was chosen for this purpose. The special server initiates a request to one of 
the share servers, S
1 
in this case, and S
1 
randomly chooses a set of servers to participate in 
this transaction. Once the Special Server is notified of his alliance partners, he contacts 
them individually sending them the hash of the message M and asking for their signed 
shares. Meanwhile, the Special Server computes his own signature share. Once he 
receives all the shares, he and computes the complete signature. For purpose of 
verification of authenticity he verifies the signature using the public key (N, e). The 
signature is deemed valid only if the correct keys were applied. 
4.4 Test Cases 
Test cases for the implementation were designed to measure time taken for key 
generation, time to compute a signature, scalability and robustness.