Trust assumptions

The security of a CKKS deployment depends on a number of trust assumptions about its participants. The standard assumption is that everyone is honest-but-curious: each party follows the protocol exactly as specified, but may try to extract whatever information they can from the messages they legitimately see. Below we describe what each participant must be honest about, and what can go wrong if they aren't.

The server

[WORK IN PROGRESS]

The server is expected to execute the agreed-upon arithmetic circuit faithfully. A malicious server can hand the decryptors a ciphertext that actually decrypts to sensitive information — for instance, a single party's raw input — while telling them it is the result of a computation whose output was safe to reveal. The decryptors, trusting that claim, decrypt the ciphertext and unwittingly publish the leaked information.

Multiparty participants

[WORK IN PROGRESS]

During multiparty key generation and decryption, each party is expected to follow the protocol exactly — sampling its secret-key shard honestly, broadcasting the correct public-key, relinearization-key, and rotation-key contributions, and producing well-formed partial decryptions at the end. A party that deviates from the protocol can corrupt the joint keys or the final decryption, so the result the rest of the parties recover is wrong or nonsense.

Encryptors

[WORK IN PROGRESS]

Whoever performs an encryption is expected to encrypt the actual input they are contributing — not a probe of their own design. A malicious encryptor can submit a specially crafted plaintext to try to extract information about either (a) the function being computed in a standard FHE use case, or (b) the other parties' inputs in a multiparty use case. This can be partially mitigated by interleaving fake trial runs with real computations: since the cheater cannot tell which run is real, they can cheat at most once before being detected.