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

Thanks! The secret client key stays in the browser or app. It's used to encrypt queries, and decrypt the server responses.

Crime is illegal, best to leave that up to various law enforcement agencies.

While talking about a crime is illegal, it is the person(s) talking about the crime that are criminals, not the letter it is written on.

We don't think this guarantee is only useful to bad actors, in the same way that end-to-end encryption has turned out to be useful even if you're not doing something illegal.

The businesses using Blyss want to perform tasks (like scanning for breached credentials) without seeing sensitive customer data. Even the US government's civilian cybersecurity agency, CISA, recommends that you use end-to-end encrypted solutions for credential vaults (https://www.cisa.gov/news-events/cybersecurity-advisories/aa... Blyss is an added layer for these services, protecting even access metadata.

Individuals have a right to privacy. This right is not contingent on there being no bad actors on the planet. If anything, the existence of bad actors reinforces the right to privacy of good actors.

Sure! End-to-end encryption (E2EE) in a messaging context is about the service provider (Meta for WhatsApp, Apple for iMessage) not learning the contents of messages sent on the platform. E2EE also gets used when referring to backups, where it again refers to the service provider of the backups not learning the contents of backups.

Private retrieval is a more general concept, which refers to retrieving data from a server without letting it learn your access pattern. In a specific application, it's easier to see the contrast: for example, in our password checker (https://playground.blyss.dev/passwords), the data that Blyss helps keep encrypted, and prevents the server from learning, is which password you are checking. With standard E2EE techniques, it would not really possible to keep your query private.

In messaging, Blyss can be used to build messaging services that not only do not learn what you say (the standard E2EE guarantee), but also do not learn who you talk to. We're working on this, but it's a tricky thing to ship.

It's 1-2 seconds for a 1 GB database with millions of items.

(A couple years ago this was more like minutes, and about 10 years ago it would have taken hours!)

It's FHE applied to solve a variant of oblivious transfer, called "private information retrieval" (https://en.wikipedia.org/wiki/Private_information_retrieval). PIR is very similar to oblivious transfer, except that in oblivious transfer, the privacy is mutual - the client learns exactly one element from the database; in PIR, it's ok if the client learns some number of 'extra' items other than the one it queried.

A big part of this company has turned out to be figuring out how to explain FHE :)

I'm working on a higher-level "why/how to use this" blog post that should help. Thanks for the suggestions!

I'm trying to understand too so please correct me if this is wrong.

As I was able to gather it's like, you send them a camera which can only hold one picture.

Then they use this camera to scan every document they have. The trick is that this camera will only save the picture, without revealing them which one, of the record you are interested in.

When they finish scanning all the documents, they send you back the camera which now has a single picture of the document you wanted, and than only you can access.

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 unstructured accesses. This is too big to fit in even the largest CPU L3 caches, so DRAM bandwidth is still relevant. It may be eventually be feasible to build an ASIC with this much on-chip memory, but in the meantime, GPUs do a pretty decent job with their massive HBM bandwidth.

Great question! The ciphertexts will be different every time, just like in standard encryption; the scheme uses something very similar to a nonce.

We are trying to avoid the "ECB Penguin", of course: https://crypto.stackexchange.com/questions/14487/can-someone...

Some data, like passwords or other credentials, isn't stuff anyone really wants to monetize - so secrets managers (things like HashiCorp Vault) and password managers are both interested in using this to allow them to collect even less data.

In other cases, for the same compliance and data security reasons behind the desire for on-prem, larger enterprises prefer that their SaaS vendors collect as little data about them as possible. Blyss can get you the best of both worlds: the data security of on-prem, with the convenience and ease-of-deployment of SaaS.

Things tend to get pretty slow when you try to compute SNARKs over FHE computations. Some progress is getting made, but it's still pretty academic.

There is a cool company trying to instead use FHE to accelerate SNARKs: https://github.com/Sunscreen-tech/Sunscreen. They seem to be making some headway!

Assuming the malicious server operator, you need to obtain the client out-of-band (package manager, app store etc), or if we require it’s the web app - thru somethink like an IPFS gateway where you can be sure the bits received match a particular hash.

Or do a git clone (pinned to commit hash) and host the client locally, I guess))

Yeah, this is definitely a risk of any in-browser demo of this tech. The story for apps is much better, since there's a routine installation process, signatures are checked, etc. We'd like private retrievals to eventually be part of the browser itself, so that it can make a kind of "private GET" request natively.

We'd also love to bind our client JS code to a hash of our build output from GitHub, but as of now there's no simple way to do this that the browser will pin automatically - integrity checks are good, but don't prevent the server from just changing the hash. We've toyed with writing an extension for this, but haven't gotten around to it.

Thanks! Yup, private retrieval is interesting as a product because it's a fundamentally new capability; there aren't really competitors we can show incremental improvements against. If you're still interested in the space, we'd be happy to compare notes! Feel free to email us: founders AT blyss.dev

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 implemented this system for our private password checker, which tests passwords against almost a billion breached credentials: https://playground.blyss.dev/passwords

You can store the nodes of a search tree (e.g. with three levels year/month/day) on Blyss and use that. Of course you’d need to maintain that search tree yourself.

wouldn't salting and hashing be enough for this use case if you keep the salt on the client?

Same problem as “hash the PIN code”, an attacker can run the algorithm for Alexa-1M.csv.

The most logical way would be to a copy of your vault stored locally when you first login (then kept in sync using shared secret with the server) - as far as I known most password managers work this way (no idea for bitwarden). This should enable schemes when it can check locally if your vault contain a given website, rather than having to reach a server for each website you visit.

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 overheads.

I haven't read their protocol, but you can easily implement PIR using FHE through polynomial evaluation.

The main thing we'd like the security review to focus on is our Rust client code. We'd also really like to select for a reviewing team that has a deep level of familiarity with cryptography. We would provide the team with a summary of the sensitive operations involved in lattice-based key generation, so that lattice experience would not need to be a hard prerequisite to understanding the code.

To answer my own question, yes, not only would PIR on Tor Onion Service enable anonymous access of data via an anonymous connection, but there other possible uses of PIR for Tor. Notable example being "PIR Tor" — which is a Tor architecture that would change Tor from being P2P to client-server:

https://www.usenix.org/conference/usenix-security-11/pir-tor...

Sure, we'd love to talk! Hardware acceleration is really cool. Send us an email: founders @ blyss.dev.