Hi,
I want to ask if there are any plans to provide interoperability feature between ciphertexts in ConcreteML and TFHE-rs libraries? If yes, do you have a time estimate for when it will be made available?
Sharing some context below on how and where I want to use this feature.
I am building a cryptographic protocol that uses FHE and in addition needs to give Zero-Knowledge Proof that a FHE ciphertext and an El Gamal ciphertext encrypt the same values. For ZKP, I am using Cut-and-Choose style proofs. Part of the witness required in generating these proofs is the randomness underling a FHE ciphertext. I have augmented TFHE-rs library to access the randomness underlying TFHE-rs ciphertexts. Next, I want to use the cryptographic protocol I built for demonstrating two applications: (1) computing degree 3 functions under FHE and (2) fine-tuning ML models under FHE. For application (1), I used Concrete library and its interoperability feature with TFHE-rs to enable the ZKP. For application (2), I want to use ConcreteML library since it provides ML algorithms out of the box. I also want to reuse the ZKP I wrote in TFHE-rs here. I think an interoperability feature between ConcreteML and TFHE-rs would solve this problem.
Thank you,
Nikhil
Nice ideas, thanks for sharing !
Concrete ML is adding TFHE-rs interoperability for some models (for tree classifiers it was merged).
However, it is not available for other models, or logistic regression training. For hybrid models fine-tuning (for LLMs) encryption is done with TFHE-rs GLWE ciphertexts (not the radix ones but conversion from radix Fhe[U]Int[XY] to GLWEs can be done).
For which one of these models would you need support for TFHE-rs ciphertext interoperability?
Thanks for sharing about tree classifiers, I will take a look at it.
The scope of my work is less tied down to a specific ML model, and is more about demonstrating how to do this in general. In a little more detail, the cryptographic application is for enabling fair exchange of data and payment on a blockchain. A seller holding data x wants to get paid some money from a buyer and in exchange will sell f(x, y) to the buyer. Think of x as a proprietary and high quality dataset held by the seller, y as a ML model held by the buyer and f(x, y) as the fine-tuning of the model y on dataset x.
Right now, I am working with fine-tuning SGD classifier under FHE since ConcreteML supports it so far. So in the short term, interoperability for that would suffice. But general interoperability between ConcreteML and TFHE-rs would be more helpful in the longer run to broaden the scope of what all functions can be supported in practice in the aforementioned fair exchange scenario.
I assumed a single bridge for interoperability between ConcreteML and TFHE-rs would suffice for all ML models built in ConcreteML. But from your response, it seems different ML models use different TFHE-rs ciphertexts (perhaps due to optimization trade-offs?) and thus a seperate bridge requires to be built for each of them to enable interoperability. Is this the case? If yes, is there any good reference that I can read about?
A single bridge of interoperability will suffice indeed for most models - only LLM fine-tuning uses a different ciphertext format for now.
We’ll soon be adding tfhe-rs interoperability for LogReg training, but I can not commit to a concrete time-line.
I can summarize the trade-off between the different ciphertext types as:
- LLM fine-tuning is implemented as a two party protocol where only linear operations are performed on the server side. For linear operations we use a packed ciphertext and packed linear operations are faster.
- all other models, including Logistic Regression training - include non-linear operations using PBS. the PBS doesn’t work on packed ciphertexts, so all of these models use the LWE “native” ciphertext, and will soon also support TFHE-rs LWE “radix” ciphertexts . Radix ciphertexts break up a big bitwidth value in small bit-width blocks