Launch HN: Blyss (YC W23) – Homomorphic encryption as a service

Post by dariosalvi78 » Tue, Mar 14, 2023, 9:45 PM UTC

neilmovva wrote: post #41

dariosalvi78 wrote: post #38

this is great, thanks for launching it, I may actually be a future user of yours ;) one important feature I see missing is that one cannot run queries with comparisons, such as "give me any message sent between 2022-10-10 and 2023-02-01". This would be very important when one doesn't have all the keys, or when the keys are too many, like in the messages example above. Any idea for this kind of scenario?

Thanks! Yup, it's not always practical to make a huge number of queries when you expect many of them to come back empty. Instead, we first perform private lookups against a Bloom filter, to find out which keys actually hold data (e.g. messages). Then, we privately retrieve only the useful keys. The Bloom filter is also served over Blyss, so the server still learns nothing about which keys you're interested in. We imp…

Post by byteware » Tue, Mar 14, 2023, 10:11 PM UTC

neilmovva wrote: post #18

robszumski wrote: post #16

Are there any hardware acceleration strategies for FHE or is it all making the calculations more efficient on the software side right now? My guess is that the software needs to mature before baking silicon?

Our FHE scheme uses lots of Number Theoretic Transforms (NTTs), which are pretty computationally expensive. NTT is a good candidate for acceleration, and there is quite a bit of interest from the zk community in doing so ( https://www.zprize.io/prizes/accelerating-ntt-operations-on-... ). From a hardware perspective, NTT can be done in parallel, but has a fairly large working set of data (~512 MB) with lots of unstru…

Post by blintz » Tue, Mar 14, 2023, 10:24 PM UTC

ngneer wrote: post #43

This capability is not exactly Fully Homomorphic Encryption (FHE). In the cryptographic literature this is typically referred to as PIR, or Private Information Retrieval [ https://en.wikipedia.org/wiki/Private_information_retrieval ]. Counterintuitive indeed. The idea is not totally new, though...

Post by ngneer » Tue, Mar 14, 2023, 11:05 PM UTC

blintz wrote: post #46

ngneer wrote: post #43

This capability is not exactly Fully Homomorphic Encryption (FHE). In the cryptographic literature this is typically referred to as PIR, or Private Information Retrieval [ https://en.wikipedia.org/wiki/Private_information_retrieval ]. Counterintuitive indeed. The idea is not totally new, though...

True! We are using FHE to perform PIR. The underlying scheme we use is a real homomorphic encryption scheme (Regev + GSW), but yeah, we explicitly do not support performing arbitrary computation on encrypted data. As it turns out, that's still quite slow - the Google FHE C++ transpiler still takes seconds to do 32-bit arithmetic operations. Our PIR system is able to achieve much more practical speed + communication o…

Post by blintz » Tue, Mar 14, 2023, 11:47 PM UTC

dariosalvi78 wrote: post #42

neilmovva wrote: post #41

Earlier quoted context omitted.

Thanks! Yup, it's not always practical to make a huge number of queries when you expect many of them to come back empty. Instead, we first perform private lookups against a Bloom filter, to find out which keys actually hold data (e.g. messages). Then, we privately retrieve only the useful keys. The Bloom filter is also served over Blyss, so the server still learns nothing about which keys you're interested in. We imp…

Thanks for the answer, but I was meaning from your customer perspective. My understanding is that you offer a key-value store, so the only operation available on the encrypted data is a comparison (==). If my application wants to retrieve data within a certain range ( operators) is there anything I can do to implement it on top of you SDK? Think of the encrypted messages app: how can I retrieve this month's messages…