rhindi

They use BFV, which is an FHE scheme allowing a limited number of fast additions and multiplications (enough for their use case).

Zama uses TFHE, which allows any operation (eg comparisons) with unlimited depth.

So if you only need add/mul, BFV, BGV and CKKS are good options. For anything else, you better use TFHE

There are some non-ML based approaches for ultra low field MRI that are starting to work: https://drive.google.com/file/d/1m7K1W--UOUecDPlm7KqFYzfkoew... . You can still add AI on top of course, but at least you get a better signal to noise ratio to start with!

FHE in general is efficient enough for many applications now. You can see some benchmarks here: https://docs.zama.ai/tfhe-rs/getting-started/benchmarks

We are planning several other blog posts to explain all the details.

In the meantime if you want a good introduction to the FHE scheme we use behind the scene, you can take a look here: https://www.zama.ai/post/tfhe-deep-dive-part-1

Multiple teams are working on FHE smart contracts, including us, so it’s definitely happening. Adding ZK to the mix would be awesome for scalability and indeed to avoid replicating the FHE computation

It’s much much faster now, and performance is improving 10x every couple of year. With the current trend, FHE will be applicable to 80% of usecases by 2025

Have you considered using FHE for analyzing the photos encrypted?

Yes, in practice however it makes a difference. Consider for example computing the ReLu function for a neural network:

- With boolean circuits you need to run dozens of boolean gates, which means a lot of underlying crypto ops. Works but expensive.

- with arithmetic circuits, you would approximate it using polynomials. Works but not with high precision.

- with functional circuits, you encore the function as a single “bootstrapping” operation. Works in a single crypto op.

Performance / precision tradeoffs will be very different in these 3 cases

It's really great to see more big companies getting into this game, ease of adoption is really the key here.

When it comes to FHE, there are 3 underlying paradigms you can target with compilers:

1. boolean circuits, where you represent your program as encrypted boolean gates. The advantage is that it's as generic as it gets, the drawback is that it's slow. TFHE is great for that, and it's what is shown here.

2. arithmetic circuits, where you represent your program as a combination of encrypted additions and multiplications. This goes much faster, but you are quickly limited in terms of usecases because you can only do a certain number of arithmetic operations. CKKS/SEAL targets that: https://www.microsoft.com/en-us/research/project/microsoft-s...

3. functional circuits, where you represent your program as a combination of homomorphic functions. Advantage is that you can do very complex things like deep neural network, the drawback being that you have limitations of the bits of precision for the computations. Concrete targets that: https://zama.ai/concrete/

If it helps, we did a mini site to explain FHE: https://6min.zama.ai

8 bit is definitely doable today, fast

There are basically 2 strategies:

- do fast operations, with a limit on how many you can do. This is called Leveled Homomorphic Encryption, with CKKS being the most popular scheme. Microsoft open sourced a lib called Seal for it.

- do unlimited operations, but with extra overhead. This is called Fully Homomorphic Encryption, with TFHE being the fastest implementation. My company Zama has open sourced an library in Rust called Concrete.

Reminds me a lot of deep learning in 2010, just before it took off!

Homomorphic encryption, which enables you to process data without decrypting it. Would solve privacy / data security issues around sending data to be processed in the cloud

Just dual license your code with an AGPL and commercial license. Proprietary software companies hate AGPL, and won’t take the risk to use it, instead preferring to pay your commercial license. MongoDB does that very successfully!

Nice overview! A few comments:

- homomorphic encryption is much much faster now, so the latency argument against won’t hold much longer

- with multi-key FHE, you could replace MPC, without the integration complexity and increased bandwidth cost

- Trusted Execution Environments are not about protecting user data (that’s the purpose of FHE) but rather about protecting the software itself from people having access to the physical machine. An example would be running a sensitive ML model in the cloud: you would want to use FHE to process the user data encrypted, inside an TEE that would protect your model from the cloud vendor.

Homomorphic encryption and the trend of making everything end to end encrypted online. Puts an end to surveillance, data theft, and complex regulatory frameworks. Makes people feel safe about using online services, and makes companies feel safe using third party cloud services.

Yes, turns out you can convert ciphertexts from one scheme to another, so you can go back and forth between them depending on what type of computation you are trying to do. However the cost of transciphering is high, so in practice it doesn’t work well. But give it a few years and it’ll work!

The server doesn’t need the decryption key, ever. Thats the whole point in fact. FHE is end to end encryption for compute. However there is sometimes a public key used, called an evaluation key.

All FHE schemes today add tiny random noise to the ciphertext so that encrypting the same data twice give different results. The noise is then kept to a nominal level as you compute homomorphically using a special operation called bootstrapping. Then when you decrypt, you just ignore the noise and get your result. If you do that well and dont let the noise grow too big, you get very strong security.

Fwiw, bootstrapping is actually what makes FHE slow, not the actual addition/multiplication etc

I suggest looking at TFHE and SEAL for starters

You have formulas to calculate the security level given a threat model, so the compiler could in theory do it automatically. Just specify that you wants 128 bits of security or whatever, and it will do the rest.

All modern FHE is lattice based, so pretty strong if you chose the right parameters. But of course if you dont chose secure parameters.. well, it wont be secure :)

There are tools to measure the security level of FHE schemes: https://bitbucket.org/malb/lwe-estimator/

There are two main approaches to FHE: homomorphic boolean circuits and homomorphic numerical processing.

In the former (eg Cingulata), you convert a program into a boolean circuit, and evaluate each gate homomorphically. While this is general purpose, it also means you decompose functions that could be done in one instruction into multiple binary operations (so very slow). That’s usually what people refer to when they say FHE is slow.

The other approach consists of operating directly on encrypted integers or reals, and finding ways to do more complex computations (like a square function) in one step. While this is obviously much faster, it is also limited to whatever operations is supported by the scheme. This is what people refer to when they say FHE can only do certain things.

For years, the tradeoff has basically been slow and general purpose, or fast and limited. But there are new scheme being worked on that will be published soon that enable to go way beyond what’s currently done, such as doing efficient deep learning over encrypted data and other complex numerical processing.

Lots is coming out of labs and will be on the market within 2 years!

Actually homomorphic encryption always ends up running as slow as the worse case, so you can’t do a sidechannel attack by looking at the computation time.

Yes, all the fully homomorphic schemes are lattice based and thus thought to be quantum resistant

It’s starting to, yes, in particular for machine learning. There is a yearly competition called iDash where people show the performances of their homomorphic schemes. This year should be very interesting

Some of the newer schemes are much faster. The recent progress feels like deep learning in 2010, right before everyone realized it worked

There are as many usecases as there is sensitive data! Some of the obvious ones are automated medical diagnosis, genomics, biometric authentication, fraud detection, etc. What has prevented those usecases from happening at scale is the performance of homomorphic schemes

Hi everyone!

I am a co-founder at Snips. This is a new product we are working on, which is due for next year

You can read more about it here https://medium.com/snips-ai/snips-air-a-private-by-design-op...

We will be publishing our whitepaper in the coming weeks, and are welcoming any feedback!

Cheers

It started as we wanted to avoid using credit cards and thus having to identify users (the whole point of this new product is 100% privacy). The token will be user to run a TCR-like appstore on the consumer side, and to incentivize people to participate in federated learning developer side.

I can guarantee it is not! We are a VC backed, 60 people AI team from Europe, having worked on AI for a few years. This is a new product we are launching next year