Concrete-ML: The Case for a Public Key

Hello Concrete-ML Team,

I’m a user interested in privacy-preserving ML with FHE. Concrete-ML’s two-key system (Client Key for encryption/decryption, Server Key for evaluation) is efficient but lacks a separate Public Key (pk) for encryption, unlike standard FHE schemes with three keys (pk, sk, evk). Adding a Public Key would enhance interoperability, enable secure multi-party computation, and prevent privacy breaches in scenarios like federated learning or shared circuits (e.g., healthcare or finance), where clients encrypting data shouldn’t decrypt others’ data.

Why it matters:

Supports secure multi-party setups (e.g., banks collaborating on encrypted risk analysis) by ensuring encrypting parties can’t decrypt, preserving privacy.

Aligns with standard FHE practices, improving compatibility and user onboarding.

Minimizes key exposure risks in distributed environments.

Please consider this for your roadmap. Great work on Concrete-ML!

1 Like

Public key encryption is already available in the backend library (tfhe-rs) and is already used in the blockchain product. Concrete ML does not support this yet.

Multi key encryption isn’t implemented as this has a huge cost in performance.

1 Like