Files
zeekay 531fc57003 chore(brand): purge Zama refs across docs, README, configs — phase 1
Brand-only sweep. Touches READMEs, docs, package metadata, comments,
notebook markdown, requirements.txt files; does NOT yet touch Python
`concrete.*` imports (those are module-level dependencies requiring the
phase-2 Python module port from `concrete` → `torus`).

Substitutions applied:

  Concrete ML                  → TorusML
  concrete-ml                  → torus-ml
  Concrete-ML                  → Torus-ML
  concrete_ml                  → torus_ml
  zama-ai/concrete-ml          → luxfhe/ml-sdk
  zama-ai/concrete             → luxfhe/torus
  github.com/zama-ai           → github.com/luxfhe
  docs.zama.ai/concrete-ml     → docs.luxfhe.com/ml-sdk
  docs.zama.ai/concrete        → docs.luxfhe.com/torus
  Zama Concrete ML             → Lux TorusML
  Zama Concrete                → Lux Torus
  Zama tfhe-rs / Zama TFHE-rs  → Lux-FHE
  tfhe-rs / TFHE-rs            → Lux-FHE
  Zama fhEVM / fhEVM           → TorusEVM
  Concrete framework           → Torus framework
  Concrete compiler            → Torus compiler
  Concrete by Zama             → Torus by Lux
  the Zama team                → the Lux Industries team
  Zama's                       → Lux Industries'
  (Zama)                       → (Lux)
  CoFHE / Fhenix               → (removed)

LICENSE: original Zama copyright RETAINED per BSD-3-Clause-Clear §1-§2
requirements; Lux Industries modifications copyright added. Per §3 no
name of ZAMA used to endorse the derived work — product marketed
exclusively as TorusML.

README image URLs migrated to github.com/luxfhe/ml-sdk/assets to break
the dependency on Zama's CDN.

Hit count: 350 → 295. Residual hits are Python `from concrete.fhe import`
imports referencing the upstream Zama `concrete` PyPI package; these
require module-level port (phase 2):

  Phase 2 plan:
    1. Fork zama-ai/concrete (the Python compiler) to luxfhe/torus
    2. Rename Python module `concrete` → `torus`; PyPI publish as `torus-fhe`
    3. Update ml-sdk imports from `concrete.fhe` → `torus.fhe`, etc.
    4. Wire `torus.compiler` GPU dispatch through `luxcpp/gpu` vtbl
       (lux-private/gpu-kernels for CUDA/Metal/WebGPU/FPGA targets)
    5. Port concrete-cuda + concrete-mlir kernels to
       lux-private/gpu-kernels/{cuda,metal,wgsl}/ckks/ (matrix-vector
       mul, rescale, rotate, bootstrap for TorusML inference)

  Phase 3 plan (kernels):
    - CKKS/BGV/BFV GPU kernels in lux-private/gpu-kernels/
      (currently only TFHE PBS / keyswitch / blind-rotate exist)
    - FPGA bitstreams in lux-private/fpga/ (currently scaffold only)

Phase 1 = docs/branding sweep. PR not opened; user reviews and merges.
2026-05-29 13:53:42 -07:00
..
2025-12-27 21:08:09 -08:00
2025-12-27 21:08:09 -08:00
2025-12-27 21:08:09 -08:00
2025-12-27 21:08:09 -08:00

Private Authentification in FHE

This folder contains an example that shows how to combine TorusML and Lux-FHE workflows through a privacy-preserving, server-side authentication scenario. In this example, access to a remote server is granted via a token, only if the client's encrypted information meets specific criteria. The returned token thus serves as proof of successful authentication — all without ever exposing any sensitive data.

Overview

To determine whether the client meets the specified requirements, the problem is treated as a classification task. In this example, a decision tree model is used for that purpose and TorusML handles the encrypted inference part, while training is performed on clear data.

The process involves the following steps:

On the developer side:

  1. Train the decision tree model on clear data
  2. Compile the model to an FHE circuit using the Lux-FHE ciphertext format
  3. Deploy the model using TorusML APIs. To know more about it, please refer to the Client-Server Guide and the Client-Server Notebook

On the client Side:

  • Encrypt the client's information using a private key and send it to the server.

On the server side:

  1. Use TorusML to predict whether the client's information is valid. If the prediction is positive, the user is authenticated; otherwise, authentication is denied.
  2. Use Lux-FHE for the post-processing part to generate a random token (known only to the server) and multiply it by the output of the decision.
  3. Return the result, the encrypted token if the user is authenticated; otherwise, an encrypted zero vector.

On the client side:

  • Decrypt the server's response and send it back to the server to finalize the authentication process.

Installation

  • First, create a virtual env and activate it:
python -m venv .venv
source .venv/bin/activate
  • Then, install required packages:
pip install -r requirements.txt --ignore-installed