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

Swift Homomorphic Encryption

swift.org

Post reply on HN
Print view View original

41–50 of 135 posts

Re: Swift Homomorphic Encryption

#41

Post by cedws »

osaariki wrote: post #13
bluedevilzn wrote: post #2

This must be the first real world use case of HE. It has generally been considered too slow to do anything useful but this is an excellent use case.

Edge's Password Monitor feature uses homomorphic encryption to match passwords against a database of leaks without revealing anything about those passwords: https://www.microsoft.com/en-us/research/blog/password-monit... So not the first, but definitely cool to see more adoption!

This is nicer than the k-anonymity algorithm that Have I Been Pwned uses, but probably an order of magnitude more expensive to run.

Re: Swift Homomorphic Encryption

#42

Post by saagarjha »

jancsika wrote: post #34
tombert wrote: 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…

Digression-- this is a good example where the mumbo jumbo that anarchists buzz on about applies in a very obvious way. You were literate in that domain. The interviewer wasn't. In a conversation among equals you'd just continue talking until the interviewer yielded (or revealed their narcissism). The other interviewers would then stand educated. You see this process happen all the time on (healthy) FOSS mailing lists…

> In a conversation among equals you'd just continue talking until the interviewer yielded (or revealed their narcissism). The other interviewers would then stand educated. You see this process happen all the time on (healthy) FOSS mailing lists.

Yeah, what actually happens is that both parties think they are right and keep yapping until someone "yields" by being so fed up that they don't want to argue anymore. Everyone else watching learns nothing.

Re: Swift Homomorphic Encryption

#43

Post by saagarjha »

7e wrote: post #16
bluedevilzn wrote: post #2

This must be the first real world use case of HE. It has generally been considered too slow to do anything useful but this is an excellent use case.

A TEE would be a cheaper and more straightforward solution, though.

They also mean if you break the TEE then your privacy guarantees are lost. This, of course, has happened many times.

Re: Swift Homomorphic Encryption

#44

Post by bawolff »

jancsika wrote: post #34
tombert wrote: 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…

Digression-- this is a good example where the mumbo jumbo that anarchists buzz on about applies in a very obvious way. You were literate in that domain. The interviewer wasn't. In a conversation among equals you'd just continue talking until the interviewer yielded (or revealed their narcissism). The other interviewers would then stand educated. You see this process happen all the time on (healthy) FOSS mailing lists…

> You see this process happen all the time on (healthy) FOSS mailing lists.

In a FOSS mailing list, someone would hopefully just link to wikipedia.

No amount of arguing is going to resolve a duspute about definitions of terms.

Re: Swift Homomorphic Encryption

#45

Post by saagarjha »

dboreham wrote: post #40
ReptileMan wrote: post #31

What is the processing that the server does on the encrypted phone number? I am not sure I understand. I always thought that this type of encryption was (roughly and imprecisely) - you send some encrypted blob to the server, it does some side effect free number crunching on the blob and returns the output blob. You decrypt the blob and everyone is happy. But to return information if some number is spam it has to be e…

The "side effect free number crunching" in this case is: is in You're on the right track with the idea of hashing -- I find it helpful to explain any fancy encryption scheme beginning with "if it were just hashing", then extend to "well this is a very fancy kind of hash", and now I kind of understand what's going on. Or at least it's no longer magic.

I don't think the set of bad numbers needs to be encrypted.

Re: Swift Homomorphic Encryption

#46

Post by fragmede »

MBCook wrote: post #36
colmmacc wrote: post #14

Earlier quoted context omitted.

My understanding of encrypted search in FHE is that there can be multiple copies of the same search key, and that search keys aren't simply in-place encrypted versions of themselves - as encrypted fields in a database are - but are mappings embedded in a higher dimensional space that is encrypted. That reads like sci-fi nonsense, but the "on the metal" result is that a search key will translate to a set of memory loc…

Do I have this right? If the server could actually decode things it would’ve gotten something that could be decrypted into let’s say 15 phone numbers. A little bit like if they were hashed, to simplify. So the answer the server returns isn’t who the phone number belongs to, it’s who those 15 phone numbers belong to. And then the client can decrypt it and just get the one that it cares about. But unlike if you were ju…

Theoretically it can, but the tech isn't quite there yet, so we don't know for sure.

Re: Swift Homomorphic Encryption

#47

Post by bawolff »

gumby wrote: post #5

The name is hilarious because HME is anything but speedy -- by many orders of magnitude. I think the real fix is secure enclaves, and those have proven to be difficult as well.

Its like high-temperature super conductors, its all relative.

Re: Swift Homomorphic Encryption

#49

Post by tempay »

MBCook wrote: post #38
tempay wrote: post #30

Earlier quoted context omitted.

That's not the use case mentioned here. The example given is blocking known spam callers and displaying identity information on the incoming call screen. To do this without homomorphic encryption requires the entire DB to be sent to every client. Even if size wasn't an issue (which it is), it's hard to update it frequently. Homomorphic encryption means you can ask Apple "who is calling me" without Apple knowing who i…

Not really. You could do it the way the Have I Been Pwned database works. You hash your query and then send only the first X number of bits. The server returns all results that hash up to that same first X number of bits. The server doesn’t know exactly what number you were looking for, and you don’t have to download the entire database. But in this case the server WOULD be able to figure out the set of possible phon…

Indeed, I wasn't clear enough in my original message that it was under the assumption that you want to keep the caller 100% private from Apple.

Though there is a valid argument that you're still leaking information (e.g. "Person X received a call at 21:05:43"), but I'm not sure how you could possibly make an API that avoided that given the time sensitive nature of identifying callers.

Re: Swift Homomorphic Encryption

#50

Post by GTP »

nmadden wrote: 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".
Post reply on HN