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

61–70 of 80 posts

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

#61

Post by O__________O »

O__________O wrote: post #55

Seems like combining this with Tor onion service would be a natural fit putting aside potential legal or ethical issues. Any thoughts on the topic?

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

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

#62

Post by osigurdson »

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 = key * database

That sounds like loading the entire database every time. If true, I do understand how the system cannot possibly would not know which item was retrieved but not clear on how the entire database isn't loaded every time.

"Cryptographic proof that the server is not spying..."

I don't understand how this is possible. If the service is implemented to remember the key, perform the request and return the result how can cryptographic proof be provided.

In any case, this definitely seems like a very cool and useful project. I struggle to understand / trust it a little but perhaps I'll eventually become comfortable with it.

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

#63

Post by ngneer »

blintz wrote: post #49
ngneer wrote: post #48

Earlier quoted context omitted.

I vaguely recall basic PIR schemes turn a database from O(n) to O(n^2). While this would be transparent to users of the service, could you comment on space overhead?

The space overhead is roughly constant (or at most logarithmic in n), and varies by the scheme. In practice, it’s something like 1.5-8x overhead. This is no big deal for storage, but does make it a pain on the memory side for processing (since the full database, including the overhead factor, needs to be resident in memory).

Awesome, thanks for taking the time to elucidate!

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

#64

Post by malf »

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…

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

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

#65

Post by mike_d »

blintz wrote: post #17
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…

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!

An advisor once told me "never build a business where your customers don't know they have the problem you solve."

Aside from the Apple and Googles of the world, how do you convince engineers and their managers that your solution solves a problem? Sure privacy is nice, but most consumers either don't think about it or simply assume it isn't private no matter what you tell them.

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

#66

Post by bauruine »

O__________O wrote: post #61
O__________O wrote: post #55

Seems like combining this with Tor onion service would be a natural fit putting aside potential legal or ethical issues. Any thoughts on the topic?

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

Tor uses a "client-server" model at the moment. All relays have to publish their server descriptor to the directory authorities (9 Tor relays run by super trusted community members). The article you linked is about how to scale the network after those become a bottleneck, where one possibility would be P2P or as they propose PIR.

What potential legal or ethical issues do you see with access via Tor onion service?

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

#68

Post by pmoriarty »

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.

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

#69

Post by forty »

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…

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.

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

#70

Post by dariosalvi78 »

layer8 wrote: post #53
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?

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.

yes, I was thinking about the same, basically the search functionality would be on me. If one has an estimation of how frequently data come in (if the search is done on time) then one could find the best approach for keeping those trees within reasonable size, maybe with a multi level approach, as you suggest.

A generic functionality that would adapt to all situations would be nicer. Maybe Blyss could offer some libraries for that?

Post reply on HN