Keep in mind that this article was written by Cornami, so i would take any assertions about cornami solving all the problems with a huge heaping of salt.

Does the ACM have submission standards anymore? They wrote the article and refer to themselves in third person.

What an amazing coincidence.

I don't know anything about Cornami's products or where they are in the manufacturing stage. However, I do work in FHE.

To give you sense of performance, today you can multiply 2 encrypted 8192-bit values in BFV with typical (not optimal) scheme parameters in 17ms on a single core of an M1 Macbook Air. This is the most expensive operation by a wide margin. The ciphertexts for these parameters is about 0.5MB and the keys are maybe a meg or two.

The algorithm you want make fast for most schemes is the Number Theory Transform (NTT), which is basically a Fast Fourier Transform (FFT) for finite fields. This algorithm has only O(nlog(n)) operations, so the computational intensity relative to memory accesses is fairly low. This stands in contrast to something nice like matrix multiplication where matrices are O(n^2) but require O(n^3)[1] computation. Unfortunately due to Amdahl's law, you have to make not just NTT fast, but all the other boring O(n) operations schemes need to do.

If you want to make FHE fast enough to justify an ASIC, you'll have to avoid data movement and basically keep everything in on-chip SRAM. Waiting 400 clock cycles for data is a non-starter. For algorithms with bootstrapping, your bootstrapping key might be 100MB, so you'll probably want a chip with like 512MB of on-chip memory to hold various keys, ciphertexts, etc. You then need to route and fan-out that data as appropriate.

You then need to also pack a ton of compute units that can quickly do NTTs on-chip, but are also versatile to do all the other "stuff" you need to do in FHE, which might include multiplication and addition modulo some value, bit decomposition, etc. And you'll probably doing operations on multiple ciphertexts concurrently as you traverse down an arithmetic or binary circuit (FHE's computational model). Figuring out the right mix of what an ALU is and how programmable it needs to be is tricky business.

For larger computations, maybe you stream ciphertexts in and out of DRAM in the background while you're computing other parts of the graph.

Making an FHE accelerator is neither easy nor cheap (easily a 50-100M+ investment), but I think it is possible. My SWAG is that you might be able to turn the 17ms latency into like 50-100us but with way more throughput to execute a large circuit graph(s).

[1]: Strassen algorithm git out of here

I feel like the real problem is that much like QC people HE people selling it as "you can do some arbitrary computation [faster/completely securely]". Both QC and HE as currently theorized are extraordinarily limited in the kind of computations that can be performed. In the case of HE I cannot see how any of the schemes could be made to perform their quintessential example of an encrypted query applied to an encrypted database producing an encrypted result. Equivalently in QC land you have Grover's algorithm making DB queries magically faster.

Old man shakes fist at clouds.

I understood about 20% of that but I really appreciate the comment.

Are there any companies doing pioneering work on this now? What aspects of FHE does your employer do? How would you say the future is looking for FHE?

We're building an FHE compiler[1] and an accompanying zero-knowlege proof (ZKP) library for proving things about encrypted quantities. As with much of today's cutting-edge crypto, we're targeting Web3 applications, as this is an area where we see immediate use cases. However, our compiler and ZKP libraries are stand-alone so you can definitely use them in other applications.

My impression is that there are many parallels computing at large where custom hardware is becoming more and more prevalent. You can run arbitrary C programs with FHE by building a CPU out of binary gates and running on that, but it will run at 1Hz[2] emulated on 8GPUs. So, computing fibonacci(5) takes like 16 minutes. Conversely, you could create an arithmetic circuit that does it in like 16us. However, working with circuits is hard, let alone the additional requirements FHE imposes.

Today, our compiler lets you write Rust code that turns into an arithmetic circuit in the BFV scheme. It also manages parameter selection, which is another annoying part of FHE: choose parameters too small and decryption will fail due to excessive noise, but larger parameters slow down the computation and make ciphertexts larger.

Overall, the FHE has a ton of promise, but is currently in the chicken and egg phase whereby there isn't much commercially available because there isn't a market because there isn't anything available. We're trying to be an egg and grow along with a market. FHE is a big area and there's a ton to explore, like multi-key encryption[3]. FHE is currently nascent, but I believe its future is bright where it can be appropriately used.

[1]: https://docs.sunscreen.tech/

[2]: https://www.usenix.org/conference/usenixsecurity21/presentat...

[3]: https://eprint.iacr.org/2020/180

If no one answers here, might try on the FHE.org discord, loads of researchers there who probably wrote a paper on exactly that.

The subreddit /r/crypto is good quality as well (some researchers there).

Any chance of an IRC or Matrix bridge?

thanks! will try there