Hacker News Reader

Hacker News

Comment by gumby | Hacker News Reader

Full thread

gumby

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.

View on HN

There was a recent paper that also uses Swift in the name:

“Cheddar: A Swift Fully Homomorphic Encryption Library for CUDA GPUs” - https://arxiv.org/pdf/2407.13055

We were a little worried, but quickly discovered that they used Swift as an adjective not as a programming language.

[Disclosure: I work on the team responsible for the feature]

> I think the real fix is secure enclaves

FTA: “Live Caller ID Lookup uses homomorphic encryption to send an encrypted query to a server that can provide information about a phone number without the server knowing the specific phone number in the request”

So, this would require a distributed Secure Enclave or one of them on Apple’s server communicating with one on an Apple device (likely, certainly over time, with lots of different Apple devices fo lots of different iCloud accounts)

I don't see why it would? IIUC, the promise of homomorphic encryption is that I can encrypt my database of contacts and send it to an untrusted server, later send the encrypted query to that untrusted server, and get back an encrypted response, without the server being able to tell anything that couldn't be told from the wire (some bounds on how much data, timing of communication, that sort of thing) or provide an incorrect answer.

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 is calling you.

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 phone numbers you were asking about. Because of the complexity of passwords the search space would be a lot larger.

So privacy wise this does seem better.

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.

https://developer.apple.com/documentation/sms_and_call_repor... has some more details on privacy in Live Caller ID Lookup.

[Disclosure: I work on the team responsible for the feature]

Thanks, that was an interesting read. Seems like a nice solution with the pragmatic trade off with trusting there isn’t collusion between Apple and the third party.

The client can constantly and at random intervals make lots of chaff queries to the API, so the service doesn't know which are real calls and which aren't. The client knows it's incoming calls history, so it can make sure it's chaff queries are statistically convincing.

For instance, if you often receive a call at the same time of day, that could be a detectable signal in the noise, unless the client then creates a lot of similar fake signals in the noise.

Ah, interesting. Yeah, they seem to point at "Private Information Retrieval" but I don't see where they explain how they do it? I see some mention of "cleartext inputs" and I guess if you can do that you can pass the whole DB that way? That sounds expensive, but I think if you want to actually keep the number completely confidential it has to touch every record - otherwise you could look at the access pattern...

I think Swift in this case is just referring to the programming language, Swift, and not a characteristic of the encryption library itself

Right, but that doesn't make it not funny.

At least 10^4 times slower than raw code, i think

That makes HE anything but Swift (

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

I didn’t look at domain at first and ended up being quite disappointed. :)

Reply on news.ycombinator.com