Compute without decrypting.
Understand the client, evaluator, keys, and encrypted values before choosing a scheme.
For application developers · Source guide · 2394fa5
The application model
A client encrypts data and keeps the secret decryption key. An evaluator receives ciphertexts and performs supported operations on them. The client decrypts the returned ciphertext to recover the result.
| Stage | Client | Evaluator |
|---|---|---|
| Prepare | Generate keys and encode inputs | Receive public parameters and required evaluation keys |
| Compute | Send encrypted inputs | Evaluate the agreed computation without the secret key |
| Finish | Decrypt and interpret the result | Return an encrypted result |
For example, a client can encrypt a vector of measurements and ask an evaluator to compute a weighted score. The weights and program may be public even though the measurements are encrypted. Private retrieval applications instead hide which database record a client requests.
FHE protects input confidentiality under the scheme’s assumptions. It does not by itself prove that the evaluator ran the correct program or hide the program from the decrypting client. Read Security and responsibilities before designing the protocol.
Choose the data you compute on
| Use case | Start with | Meaning of the result |
|---|---|---|
| Arithmetic on numerical vectors | CKKS | Approximate real or complex values, with an error tolerance |
| Boolean logic, lookup tables, integer circuits | Binary FHE | Discrete results, subject to the operation’s width and correctness conditions |
A plaintext is the encoded representation of your input. A ciphertext is its encrypted representation. A CKKS ciphertext can pack multiple values into slots. Addition and multiplication act slot by slot; summing across slots requires rotations and additions.
A slot vector is an application-level numerical vector. The polynomial limbs on the Layouts page are the lower-level representation used to implement these operations.
Keys have different jobs
The secret key decrypts and stays with its owner. A public encryption key, when used, lets another party encrypt inputs. The introductory examples use secret-key encryption instead.
Evaluation keys let the evaluator perform particular operations without receiving the secret key: relinearization keys for ciphertext multiplication, rotation keys for slot rearrangement, and bootstrapping keys for refreshing computation capacity. They can be much larger than a ciphertext.
Accuracy and computation capacity
CKKS encodes values at a scale, commonly written Δ. A larger scale can preserve smaller fractional differences, but the final error also depends on encryption noise, approximations, input magnitude, and the operations performed. Scale bits are not a guarantee of that many accurate output bits.
Poulpy tracks budget as the difference between ciphertext modulus width and encoding-scale width. It is arithmetic headroom, not a security score. Multiplication and rescaling consume headroom; additions can still increase noise and message magnitude.
Relinearization brings a multiplication result back to the usual ciphertext shape. Bootstrapping refreshes its computation budget so further operations become possible. It costs time and key material, and CKKS bootstrapping introduces additional approximation error rather than recovering already lost accuracy.
Continue with a calculation
Run the quickstart, then use Parameters and precision to connect the observed scale, budget, and error to your workload.