Handling of session IDs

[fjarri]

Session IDs and sub-session IDs for the protocols need a review. We need to make sure that:

• The implementation satisfies the requirements the security proofs in the paper are based on
• The implementation doesn't care about session IDs more than it needs to, offloading the rest to the user (e.g. if the user wants to run several concurrent processes of key share generation on the same set of nodes, it's up to them to route the messages to a specific instance of the protocol state)
• We enforce/guide the correct usage of session IDs as much as possible via the API

To be more specific (see Fig 3 for the outline):

The KeyGen protocol (Fig. 5) depends on some unspecified session ID sid (which is included in the hashes), and produces a random rid value (same for every node). Note that sid in the paper includes the curve parameters (which are currently fixed), and the sorted list of party IDs. Would it be enough to just have a random sid?

The AuxData protocol (Fig. 6) depends on ssid = sid + rid + [X] + i where [X] are the public key shares and i is the number of the party. But [X] and i are included in the hash along with ssid, and rid already corresponds to the generated [X], so I think we can take ssid = sid + rid. But since we may have to run AuxData many times (refreshing the key shares), we probably don't want to use the same ssid every time? Should we just make it entirely random? Or make it ssid = sid + rid + nonce (or a hash thereof), where nonce is incremented?

The Presigning protocol (Fig. 7) should correspond to the parameters generated in AuxData, so it should depend on ssid, and also on some nonce value (which is denoted \ell in the paper) because we may run it many times for the same AuxData parameters. Who keeps and increments the nonce? Probably the user should take care of that?

[fjarri]

106 added some use for rid, by saving it as init_id in key shares - a value that is the same for all shares created in a KeyInit run. The question still remains:

Can it be replaced by just hashing all the public shares created in KeyInit?

If the answer to this question is yes, there is a follow-up:

Can it be completely removed from KeyInit protocol, seeing as how it is already hashed alongside u_i and X_i which are random?

106 also introduces share_set_id which is supposed to be updated after each KeyRefresh (but still be the same for every keyshare produced by the refresh). Combined with shared_randomness it is used where ssid is used in the paper and (as far as I can tell) includes all the info ssid includes.