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

51–60 of 80 posts

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

#51

Post by blintz »

holmesworcester wrote: post #32
wizzard0 wrote: post #29

Earlier quoted context omitted.

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

I've wanted this too! You could include subresource integrity hash in the URL that the browser will check against the page. This would make things like Cryptpad and Skiff, or group invite links in Signal, way more secure.

This seems like it would be a cool browser standard. The browser could check that the specified SRI hash matches one published by some other entity, and then include extra information in the ‘lock’ icon or dialog, that goes further than TLS.

Usually, when I have an idea for a standard, it turns out one exists, so maybe I’ll do some digging…

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

#53

Post by layer8 »

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.

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

#56

Post by blintz »

O__________O wrote: post #54

> The SDK has not yet been security reviewed, and the public Blyss service is still in beta. Currently, what are your plans related to security audit both in terms of structuring it and context to you it would make sense?

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.

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

#57

Post by O__________O »

blintz wrote: post #56
O__________O wrote: post #54

> The SDK has not yet been security reviewed, and the public Blyss service is still in beta. Currently, what are your plans related to security audit both in terms of structuring it and context to you it would make sense?

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.

While likely expensive, when I looked around awhile back, Trail of Bits [1] to me seemed to produce the best audits for cryptographic systems, though possible there are better/cheaper options.

[1] https://www.trailofbits.com/

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

#59

Post by blintz »

zgao wrote: post #58

Hey, tangentially- I am CEO of Fabric, a company building orders of magnitude faster hardware accelerators for next-gen cryptography on the latest fab technologies. Would love to share notes if you're up for it!

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

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

#60

Post by EamonnMR »

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 efficient scheme could be achieved. Though I'd prefer, in the future, to never be renting shady or insecure servers I suppose.
Post reply on HN