The setup step of the protocol, and one of only two moments at which anything passes between a coordinating party and a site — the other being a round itself, which carries a query out and a ciphertext back. A party receives its PublicParams once, here, and from then on computes and encrypts with what it holds.
Arguments
- site
a Site, or a user-defined subclass of RemoteSite.
- ...
method-specific arguments; the built-in method takes
params, a PublicParams object.
Details
Called for you by set_workers() and make_threshold_master().
You would call it directly only when writing a RemoteSite method.
Why this is a generic
Setup is a message. For a co-located site, delivering it is an
assignment; for a remote one it is a network call that must
provision the far endpoint, and nothing in this process can do that
on the endpoint's behalf. Writing the parameters straight into a
remote proxy's state would leave the proxy looking configured
while the far end had never been told anything — a setup failure
that surfaces only much later, as a wrong answer. So the base
RemoteSite method refuses, and a subclass must implement the
provisioning it alone knows how to do. Missing remote setup fails
closed.
What crosses is public in full: a crypto context and a public key. There is no secret material in a PublicParams object and no property for one to occupy.
Reconfiguring
Receiving the same parameters again is harmless and allowed. Receiving different ones is refused. A site that silently switched keys would keep answering its first coordinator, in a key that coordinator cannot read — under CKKS that surfaces as an approximation-error abort, and under BFV or BGV as a plausible wrong integer with nothing raised. Build a fresh site instead; they are cheap.
See also
site_params() to read them back, actor-encryption for
using them, RemoteSite for the full remote contract.