From a security perspective, Constellation is designed to keep all data always encrypted and to prevent any access from the underlying (cloud) infrastructure. This includes access from datacenter employees, privileged cloud admins, and attackers coming through the infrastructure. Such attackers could be malicious co-tenants escalating their privileges or hackers who managed to compromise a cloud server.
Well, it's not about compute power and whether you can run things on-prem.
It's about sharing, synchronizing, and collaborating on data.
That's where PETs open up new opportunities.
> 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.
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.
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).
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.
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.
I agree! That's why remote attestation or simply verifiability is such an important feature of these schemes. Semantic attestation ofc means having access to the source code and that IMO makes open source the natural choice. Audits might be an option where OSS is not desired for other reasons (likely business related).
Not an expert on FHE, but confidential computing provides that attestation feature and it's just a matter of the software to make use of it.
AFAIK the problem for FHE today is the massive performance impact that makes it impractical for many applications (1000x slow-down at best). From my experience with PETs I can tell that performance is a quite sensitive topic. Especially since the shift toward cloud computing, performance bottlenecks can lead to painful costs penalties. Are you optimistic that FHE performance will improve significantly with the ongoing research?
Yeah, I‘d agree that performance is the crux of the issue for many PETs.
I am not terribly confident that over the next 5 years we will see anything like a 10x or 100x improvement in general fully homomorphic encryption.
Instead, I think we already have some domains for which FHE is really practical today (like private information retrieval), and we should focus on those. In these domains, the cost overhead of PIR is less than ~10-100x, and negligible for many real-world scenarios.
What do you expect when you read "Confidential" Kubernetes?
With confidential computing still being rather niche, the term night lack a bit of context?
