Live data from Hacker News

Swift Homomorphic Encryption

swift.org

131–135 of 135 posts

Re: Swift Homomorphic Encryption

#131
post #123

Earlier quoted context omitted.

the risk in this is that FHE is proposed as a privacy protecting tech, and it will "squeeze a lot of toothpaste out of the tube" in private data sharing, where a weakness will be a rug pull under all the data subjects whose data was shared under the aegis of being "encrypted." It's important to understand this failure mode, imo.

I don't see how a bad actor can "rug pull" when everyone has a different encryption key. A cryptographic scheme weakness is a threat to all computing systems, it's not worse for FHE. It's just that FHE relies on newer encryption than existing widely deployed crypto.

The main use case for FHE is to enable partial data sharing between parties who are forbidden from sharing data with one another, or for whom being in custody of it is too much of a liability.

the reason I think the threat is worse for FHE is because it's going to be used to share encrypted versions of private information that isn't shared today, and realistically, the only people exploiting cryptographic weaknesses right now are intelligence agencies, where in the case of a repo of FHE enciphered PII shared with a vendor is suddenly decryptable by that vendor. my point is it's not the same as other encryption for those reasons.

Re: Swift Homomorphic Encryption

#132

Earlier quoted context omitted.

Yeah but as I wrote elsewhere, the DB isn’t a KV store of plain text numbers and their encrypted representation. Instead the entire database would be encrypted and you’d do set containment operations in encrypted space which wouldn’t /couldn’t leak anything about your query (modulo unexpected side channels in the design). I don’t know how they do this efficiently and at scale with lots of updates, but maybe this data…

That could only work if the server didn't have its own database copy. Not sure how a client would be able to provide the server with a database encrypted by the client. If the server can decrypt it, it's not really safe if you're assuming server is evil

The client don't have to do that.

That's the whole point of Homomorphic Encryption. There is a Wikipedia article for that.

https://en.wikipedia.org/wiki/Private_information_retrieval

Re: Swift Homomorphic Encryption

#133
post #50
post #32

The thing that I always want to know with FHE: the gold standard of modern encryption is IND-CCA security. FHE by definition cannot meet that standard (being able to change a ciphertext to have predictable effects on the plaintext is the definition of a chosen ciphertext attack). So how close do modern FHE schemes get? ie how much security am I sacrificing to get the FHE goodness?

Is the used scheme fully homomorphic encryption or just homomorphic wrt a specific operation? Because they only mention "homomorphic" without the "fully".

With respect to IND-CCA, it doesn’t matter. Neither is compatible.

Re: Swift Homomorphic Encryption

#134
post #28

I wrote some basic homomorphic encryption code for a hackathon like 8 years ago. When I interviewed for a BigTechCo [1] about a year later, the topic came up, and when I tried explaining what homomorphic encryption was to one of the interviewers, he told me that I misunderstood, because it was "impossible" to update encrypted data without decrypting it. I politely tried saying "actually no, that's what makes homomorp…

This is pretty bad. We learned in school how RSA works, which can be easily extended to show HME multiplication at least. I can't remember it off the top of my head, but I know it's possible.

(And if I didn't learn RSA in school, I wouldn't take a strong stand on how it works)

Re: Swift Homomorphic Encryption

#135

Earlier quoted context omitted.

> but do they really care if the organization makes a promise about a secure execution environment in the cloud? Uh... demonstrably yes? No "secure execution environment" is secure against a government wiretap order. FHE is.

Unless the operating system for iPhones is open source and one can verify which version they have installed, users can't really be sure that Apple is doing this. They could just say they are doing things to protect user's privacy, and then not, and sell their data.

> Unless the operating system for iPhones is open source and one can verify which version they have installed

There are a lot of security engineers out there reverse engineering Apple's iOS versions and payloads, especially ones installed on the phones of activists and other dissidents who may be under government surveillance. While in theory Apple could build a compromised OS and serve it only to a single IP or whatever, the reputational risk if they were to be discovered would be enormous. Compared to when the processing is happening on Apple's servers, where it's impossible to tell for sure if you're being wiretapped, there's just too much of a risk of detection and tipping off the target.

Post reply on HN