zeekay
b832ba2c39
Forked from upstream concrete (BSD-3-Clause-Clear, © 2024 ZAMA) at HEAD
ecb729bb. Modifications copyright © 2026 Lux Industries Inc.
Rebranding scope:
- Python module concrete → torus (across frontends/torus-python)
- Rust module concrete-* → torus-* (across frontends/torus-rust)
- MLIR dialect concretelang → toruslang (across compilers/torus-compiler)
- Compiler optimizer concrete-optimizer → torus-optimizer
- Backend concrete-cpu / concrete-cuda → torus-cpu / torus-cuda
- Wire protocol concrete-protocol → torus-protocol
- Parameter-curves concrete-security-curves-* → torus-security-curves-*
- Public symbols concretelib → toruslib, ConcreteLang → TorusLang
- URLs github.com/zama-ai/concrete → github.com/luxfhe/torus
- URLs docs.zama.ai/concrete → docs.luxfhe.com/torus
Legal compliance:
- LICENSE.txt retains original Copyright © 2024 ZAMA verbatim (§1-§2)
- LICENSE.txt adds modifications copyright © 2026 Lux Industries Inc.
- §3 endorsement clause: Torus is marketed exclusively as a Lux product;
no Zama name used in README, docs, or marketing
- NOTICE file provides factual attribution per legal best practice
(not endorsement; required by upstream BSD-3-Clause-Clear)
README + NOTICE rewritten from scratch with Lux brand:
- Quick-start in Python (torus.fhe)
- Architecture diagram showing the gen-1 vtbl integration path
(luxcpp/gpu → lux-private/gpu-kernels for CUDA/Metal/WebGPU)
- Scheme coverage table: TFHE (luxfi/fhe), CKKS/BGV/BFV (luxfi/lattice)
- Lux FHE family table: Torus / TorusVM / TorusEVM / TorusML / TorusNet
Known limitations (phase-2A scope):
- PyPI package torus-fhe not yet published; the torus Python module
is renamed structurally but pip-installable distribution is a
follow-up (Phase 2A.1)
- MLIR dialect rename is text-level; the compiler-internal LLVM
rebuild (concrete-compiler-internal-llvm-project submodule) is
structural and works; tablegen files renamed concrete→torus but the
generated .inc files in the source tree will regenerate at build
time
- backends/torus-cuda/implementation/ is an upstream submodule
pointer to the tfhe-rs source (not fetched in the staging clone);
the CUDA backend body is delivered out-of-tree
- ~100 test-fixture variable names like concrete_encoded_sample
retain "concrete" as a math term (vs symbolic); these are inside
tests/, not the public API; cleanup is a follow-up commit
- 295 Python `from concrete import ...` residuals in luxfhe/ml-sdk
consumer remain; that repo's import update is Phase 2B
This commit is the seed for the luxfhe/torus repo. Push as the first
commit to a fresh GitHub repo; do not re-import upstream Zama git
history.
2.6 KiB
Manage Keys
This document explains how to manage keys when using Torus, introducing the key management API for generating, reusing, and securely handling keys.
Torus generates keys lazily when needed. While this is convenient for development, it's not ideal for the production environment. The explicit key management API is available for you to easily generate and reuse keys as needed.
Definition
Let's start by defining a circuit with the following example:
from torus import fhe
@fhe.compiler({"x": "encrypted"})
def f(x):
return x ** 2
inputset = range(10)
circuit = f.compile(inputset)
Circuits have a keys property of type fhe.Keys, which includes several utilities for key management.
Generation
To explicitly generate keys for a circuit, use:
circuit.keys.generate()
{% hint style="info" %} Generated keys are stored in memory and remain unencrypted. {% endhint %}
You can also set a custom seed for reproducibility:
circuit.keys.generate(seed=420)
{% hint style="warning" %} Do not specify the seed manually in a production environment! This is not secure and should only be done for debugging purposes. {% endhint %}
Serialization
To serialize keys, for tasks such as sending them across a network, use:
serialized_keys: bytes = circuit.keys.serialize()
{% hint style="warning" %} Keys are not serialized in encrypted form. Please make sure you keep them in a safe environment, or encrypt them manually after serialization. {% endhint %}
Deserialization
To deserialize the keys back after receiving serialized keys, use:
keys: fhe.Keys = fhe.Keys.deserialize(serialized_keys)
Assignment
Once you have a valid fhe.Keys object, you can directly assign it to the circuit:
circuit.keys = keys
{% hint style="warning" %} If assigned keys are generated for a different circuit, an exception will be raised. {% endhint %}
Saving
You can also use the filesystem to store the keys directly, without managing serialization and file management manually:
circuit.keys.save("/path/to/keys")
{% hint style="warning" %} Keys are not saved in encrypted form. Please make sure you store them in a safe environment, or encrypt them manually after saving. {% endhint %}
Loading
After saving keys to disk, you can load them back using:
circuit.keys.load("/path/to/keys")
Automatic Management
If you want to generate keys in the first run and reuse the keys in consecutive runs, use:
circuit.keys.load_if_exists_generate_and_save_otherwise("/path/to/keys")