Run threshold key generation across sites and construct the master

Drives the chained key-generation ceremony through the sites and returns a master wired to them. The lead site generates a fresh keypair (pk_1, sk_1); each subsequent site i derives (pk_{1..i}, sk_i) from its predecessor's cumulative public key. The final pk_{1..n} is the joint public key under which everything is encrypted.

Usage

make_threshold_master(name, crypto_context, sites)

Arguments

name: short identifier.
crypto_context: an openfhe.R CryptoContext (CKKS, BFV, or BGV) with the MULTIPARTY feature enabled. Pass features = c(Feature$MULTIPARTY) to fhe_context(). The scheme is read back from the context, so the same master drives the protocol over real-valued (CKKS) or exact-integer (BFV/BGV) arithmetic without further configuration.
sites: a list of at least two distinct, unconfigured Sites, built with make_worker(). The first is the lead site. Each ends up holding its own secret share and the joint public key. Listing one site twice, or reusing a site that already holds a share or public parameters, is an error: the repeat would discard what the first round left behind, and under BFV or BGV nothing afterwards detects the loss.

Value

a ThresholdMaster, wired to sites.

Details

Each step runs at the site, through keygen_round(): the site keeps sk_i in its own state and returns only the cumulative public key. No share is ever generated centrally, and none is returned to this function, so the master cannot hold one even by accident. Only public keys travel between parties, which is exactly what can be sent over a wire to an untrusted peer.

Decryption is n-of-n: decrypt() asks each site for a partial decryption via partial_decrypt() and fuses the results with multiparty_decrypt_fusion. There is no path by which the master decrypts alone.

The returned master is already wired, so set_workers() is neither needed nor permitted afterwards — the site order fixed by the key-generation chain is the order partial decryptions must be fused in, and re-wiring would break it.

A ceremony that fails part-way — an unimplemented RemoteSite, an unreachable endpoint, a context without MULTIPARTY — leaves no trace on the sites it had already visited: their shares and parameters are cleared before the error propagates, so the same sites can be used again once the cause is fixed. For a RemoteSite that undo reaches the local proxy only, so a remote implementation should tolerate a repeated ceremony.

What this does not defend against

The construction assumes participants follow the protocol (honest-but-curious). A site that deviates can (a) return a well-formed ciphertext that is not its honest contribution, (b) return a malformed partial decryption, which corrupts the fused plaintext silently — nothing in the scheme detects it — or (c) contribute a degenerate share during key generation, weakening the threshold. The chain is sequential, so each site also sees its predecessors' cumulative public key; OpenFHE's multiparty key generation carries no proofs of knowledge or commitments, so rogue-key behavior is not prevented here. Defending against any of this needs verifiable decryption and committed key generation, neither of which this package provides.