Which companies would use this and why? Data worth making private is also worth some $$ to the business hosting it.
Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
21–30 of 80 posts
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#22Let's say I sent up a key "foo" to get the value "bar", and I did this again and again. Will either "foo" or "bar" be encrypted to the same ciphertext again and again? Or is there some kind of nonce or salt or other mechanism that will make the ciphertext always different? Congrats on launching and thank you for any answer.
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...
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#23Awesome work, I look forward to finding applications for this.
Question: Have you considered using zk-STARKs for succinct proofs of computation? Or would that be too far off target wrt. being good at one thing?
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#24How do you guarantee the server that sent the Javascript to the browser, which stores the client secret key in the browser, didn't get hacked to also send the client secret key somewhere else after it was generated in the client?
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#25Which companies would use this and why? Data worth making private is also worth some $$ to the business hosting it.
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.
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#26Awesome work, I look forward to finding applications for this. Question: Have you considered using zk-STARKs for succinct proofs of computation? Or would that be too far off target wrt. being good at one thing? E.g. https://github.com/TritonVM
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!
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#27How do you guarantee the server that sent the Javascript to the browser, which stores the client secret key in the browser, didn't get hacked to also send the client secret key somewhere else after it was generated in the client?
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))
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#28How do you guarantee the server that sent the Javascript to the browser, which stores the client secret key in the browser, didn't get hacked to also send the client secret key somewhere else after it was generated in the client?
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.
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#29How do you guarantee the server that sent the Javascript to the browser, which stores the client secret key in the browser, didn't get hacked to also send the client secret key somewhere else after it was generated in the client?
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'…
I wonder how the Subresource Integrity can expand to the root document hash (other than using IPFS gateways).
UPD yeah, extension hashing resources sounds nice too
Re: Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
#30Earlier quoted context omitted.
Thanks! The secret client key stays in the browser or app. It's used to encrypt queries, and decrypt the server responses.
Right, but is it generated under the hood for each query? And how is the data that was initially written encrypted/decrypted? who holds the key for that?
Yes, it's generated in the browser for each query.
And this depends on the application - for example, for the private password checker, all the dumped passwords data is from a public dataset, so its not encrypted. In messaging, the data would be encrypted under the intended recipient's public key.