Swift Homomorphic Encryption
swift.org
Swift Homomorphic Encryption
1–10 of 135 posts
Re: Swift Homomorphic Encryption
#2This 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.
Re: Swift Homomorphic Encryption
#3I feel like phone number lookup is the textbook example of homomorphic encryption not actually working because there's so few keys you can simply enumerate them.
Re: Swift Homomorphic Encryption
#4I feel like phone number lookup is the textbook example of homomorphic encryption not actually working because there's so few keys you can simply enumerate them.
The novelty is that the server processing the phone number can perform the lookup without actually knowing the phone number or whether it matched.
Re: Swift Homomorphic Encryption
#5The 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.
Re: Swift Homomorphic Encryption
#6I feel like phone number lookup is the textbook example of homomorphic encryption not actually working because there's so few keys you can simply enumerate them.
I think here the query exposes who called who, which isn't as enumerable. By encrypting the query homomorphically on the client, the answering service has no knowledge of what number the lookup is for, and so Apple can't build a database of who calls you.
Re: Swift Homomorphic Encryption
#7I feel like phone number lookup is the textbook example of homomorphic encryption not actually working because there's so few keys you can simply enumerate them.
Are you thinking of hashing?
As far as I'm aware homomorphic encryption can keep even a single bit safe, but maybe I missed something.
Re: Swift Homomorphic Encryption
#8I feel like phone number lookup is the textbook example of homomorphic encryption not actually working because there's so few keys you can simply enumerate them.
I think here the query exposes who called who, which isn't as enumerable. By encrypting the query homomorphically on the client, the answering service has no knowledge of what number the lookup is for, and so Apple can't build a database of who calls you.
It includes both numbers? That wasn't clear. It sounded like they're just looking up the calling number for fancy caller id. How does the recipient affect the query?
Re: Swift Homomorphic Encryption
#9The 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.
> 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)
Re: Swift Homomorphic Encryption
#10Earlier quoted context omitted.
I think here the query exposes who called who, which isn't as enumerable. By encrypting the query homomorphically on the client, the answering service has no knowledge of what number the lookup is for, and so Apple can't build a database of who calls you.
It includes both numbers? That wasn't clear. It sounded like they're just looking up the calling number for fancy caller id. How does the recipient affect the query?
The lookup has to come from your phone, which implicitly discloses you. Encrypting the caller-id symmetrically or asymmetrically wouldn't get privacy, because the receiver would have the decryption key. Hashing it, even with a seed, would be dumb because it's enumerable as you pointed out. But encrypting the entire query does work, because it becomes on a homomorphic search on uniform looking data. So the receiver has no idea what you queried.
That said, research on things like memory access side-channels is thin here. Like if I take a guess and try a query for my guess number, are there timings there that could be exploited because of cache effects? I have no idea, but a lot of PIR schemes have fallen to this.