4 ms·

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 d

by gumby 2y ago

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.

Someone 2y ago
> 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)
- dllthomas 2y ago
  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.
  - tempay 2y ago
    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.
    - MBCook 2y ago
      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.
      - tempay 2y ago
        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.
        fboemer 2y ago
        https://developer.apple.com/documentation/sms_and_call_reporting/understanding_how_live_caller_id_lookup_preserves_privacy 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]
        tempay 2y ago
        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.
        Cyphase 2y ago
        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.
    - dllthomas 2y ago
      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...
shortstuffsushi 2y ago
I think Swift in this case is just referring to the programming language, Swift, and not a characteristic of the encryption library itself
- dllthomas 2y ago
  Right, but that doesn't make it not funny.
layer8 2y ago
I didn’t look at domain at first and ended up being quite disappointed. :)
ganyu 2y ago
At least 10^4 times slower than raw code, i think That makes HE anything but Swift (
- deleted 2y ago
  [deleted]
bawolff 2y ago
Its like high-temperature super conductors, its all relative.
karulont 2y ago
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 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]

by gumby 2y ago

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.

Someone 2y ago

> 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)

dllthomas 2y ago
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.
- tempay 2y ago
  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.
  - MBCook 2y ago
    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.
    - tempay 2y ago
      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.
      - fboemer 2y ago
        https://developer.apple.com/documentation/sms_and_call_reporting/understanding_how_live_caller_id_lookup_preserves_privacy 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]
        tempay 2y ago
        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.
      - Cyphase 2y ago
        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.
  - dllthomas 2y ago
    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...

shortstuffsushi 2y ago

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

dllthomas 2y ago
Right, but that doesn't make it not funny.

layer8 2y ago

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

ganyu 2y ago

At least 10^4 times slower than raw code, i think That makes HE anything but Swift (

deleted 2y ago
[deleted]

bawolff 2y ago

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

karulont 2y ago

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 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]