7 ms·

> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at c

> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at commercially viable speeds. At the moment, Cornami is the only commercial chip company to announce a forthcoming product that can meet and exceed that performance level. Is there any comparison performance benchmark for these Cornami chips on real world algorithms? The data given by https://cornami.com/fully-homomorphic-encryption-fhe/ https://cornami.com/fully-homomorphic-encryption-fhe/ doesn't really help me.

carrotcypher 4y ago
If no one answers here, might try on the FHE.org discord, loads of researchers there who probably wrote a paper on exactly that.
- m1ghtym0 4y ago
  thanks! will try there
- nominusllc 4y ago
  Any chance of an IRC or Matrix bridge?
- gnramires 4y ago
  The subreddit /r/crypto is good quality as well (some researchers there).
bawolff 4y ago
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.
- SV_BubbleTime 4y ago
  What an amazing coincidence.
- yazzku 4y ago
  Does the ACM have submission standards anymore? They wrote the article and refer to themselves in third person.
  - timcavel 4y ago
ricksunscreen 4y ago
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
- brokenmachine 4y ago
  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?

carrotcypher 4y ago

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

m1ghtym0 4y ago
thanks! will try there
nominusllc 4y ago
Any chance of an IRC or Matrix bridge?
gnramires 4y ago
The subreddit /r/crypto is good quality as well (some researchers there).

bawolff 4y ago

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.

SV_BubbleTime 4y ago
What an amazing coincidence.
yazzku 4y ago
Does the ACM have submission standards anymore? They wrote the article and refer to themselves in third person.
- timcavel 4y ago

ricksunscreen 4y ago

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

brokenmachine 4y ago
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?