Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 80 posts

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

#72

Post by robertlagrant »

blintz wrote: post #13
jonathan-kosgei wrote: post #8

What is the read latency?

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!)

That's impressive.

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

#73

Post by kobalsky »

wizzard0 wrote: post #14

A thing long overdue, I’d say! Have you thought about making some ELI5 explainer on how the algo essentially works? The post you link to is already a great start, I feel like it’s just a question of a little editing work and maybe more examples — for the nerds to get interested and actually read the paper — for the users to understand privacy properties better (eg why this is better than TLS in case of a server infec…

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.

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

#74

Post by neilmovva »

osigurdson wrote: post #62

I was completely lost attempting to understand this at first but I think I kind of get it now based on the documentation on the website. However, some things seem strange. If I have N items in my database, the key is length N bits. I million items = 1 million bit key. It is very likely that I am not understanding this correctly however. Does something translate a Log(N) sized "user" key to a one hot vector? item = ke…

Thanks for checking it out! Responses inline:

> That sounds like loading the entire database every time

Yup, we do perform computation over the entire database for every read - there is zero correlation between the server's work and the client's query. We currently serve queries to a 1 GB database in under 1 second. For much larger databases (100+ GB), this becomes more a question of cost: we can stay fast (1 sec) with more expense, or go slower (e.g. 5 sec) and stay cheap.

> Cryptographic proof that the server is not spying

If you trust your client software [0], then you can be sure that your request isn't decrypted anywhere outside your device. Even a malicious Blyss server cannot determine your query, because it never got a chance to see it.

[0] This level of security depends entirely on having a trusted client. Our client software is open source, and we plan to have it formally audited. We'll also publish signed desktop apps so you can be sure that you're running the same client every time.

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

#75

Post by neilmovva »

pmoriarty wrote: post #68

As someone who cares about privacy I would never trust something like this, no matter how many guarantees it advertised, though (much like duckduckgo, which I don't trust either), I might still use it anyway since the alternatives are services that more or less spit on privacy or actively work to undermine it.

Thanks for the feedback, I understand your hesitation. We don't just want to advertise guarantees - we want you to never trust third-party servers again. Fully homomorphic encryption makes this possible by never letting sensitive data even leave your device. Our job is to make this new cryptography a web standard as ubiquitous as TLS.

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

#76

Post by neilmovva »

EamonnMR wrote: post #60

At a previous job we used to rent a fair number of servers from companies we couldn't trust (and even if we did, some had security practices so bad that we couldn't be sure they didn't, for example, leave easily exploited backdoors on our boxes. We sunk a fair bit of thought into how we could get some use out of that spare compute we were paying for. Some day, maybe that problem could be solved with FHE, if an effici…

Yes, we all place a lot of trust in cloud vendors today. FHE is a way to move the trust boundary back to the client - let the server be as malicious or insecure as it wants. Raw compute could even become much cheaper, since any machine anywhere can be a supplier in the market for untrusted CPU time.

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

#77

Post by osigurdson »

neilmovva wrote: post #74
osigurdson wrote: post #62

I was completely lost attempting to understand this at first but I think I kind of get it now based on the documentation on the website. However, some things seem strange. If I have N items in my database, the key is length N bits. I million items = 1 million bit key. It is very likely that I am not understanding this correctly however. Does something translate a Log(N) sized "user" key to a one hot vector? item = ke…

Thanks for checking it out! Responses inline: > That sounds like loading the entire database every time Yup, we do perform computation over the entire database for every read - there is zero correlation between the server's work and the client's query. We currently serve queries to a 1 GB database in under 1 second. For much larger databases (100+ GB), this becomes more a question of cost: we can stay fast (1 sec) wi…

So, imagine your api endpoint looks like this:

get_data(key):

  hahaGotTheKey = key

  result = do_complicated_homomorphic_stuff(key)

  hahaGotTheResult = result

  save(hahaGotTheKey, hahaGotTheResult)

  return result
I guess you are saying the since the key is encrypted there is no way to know exactly what the user asked for. The result is encrypted so there is no way to know what it is. The only thing we know is the user asked for something and something was retrieved.

Of course, if the key is encrypted and the data is encrypted, how is it differentiated from a regular kvs? i.e.

cypherKey = encr(key) cypherData = encr(value)

kvs.put(cypherKey, cypherData)

Of course, I obviously do not understand it - this is merely a window into my flawed mental model.

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

#78

Post by paulryanrogers »

julvo wrote: post #45
themoonisachees wrote: post #40

I'm guessing this solves a very specific pet peeve of mine: When your bitwarden vault is not opened, if you log in to website, the extension will ask if you want to store the password, even if your vault already has an entry for that website. Of course, this is by design so that bitwarden doesn't store websites you have credentials for in plaintext (unlike lastpass and it blew up in their face). Would this allow your…

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

Or even a bloom filter?
Post reply on HN