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

111–120 of 135 posts

Re: Swift Homomorphic Encryption

#111

Post by GTP »

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…

AFAIK (but my knowledge is 2/3 years out of date) the problem with general computation is that current schemes are still too slow for parctical use. But recent developments give hope that it could be doable in the future.

Re: Swift Homomorphic Encryption

#112

Post by Cyphase »

tempay wrote: post #49
MBCook wrote: post #38

Earlier quoted context omitted.

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.

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.

Re: Swift Homomorphic Encryption

#113

Post by menkalinan »

I don't quite understand how the server can match the ciphertext with a value without knowing the key. How does the server determine that the ciphertext corresponds to the specific value? If the server constructs this ciphertext-value database, how does it know what algorithm to use to create ciphertext from a value and store on its side?

Re: Swift Homomorphic Encryption

#114

Post by jayavanth »

rhindi wrote: post #110
oulipo wrote: post #109

How does it compare to the FHE from https://zama.ai ?

They use BFV, which is an FHE scheme allowing a limited number of fast additions and multiplications (enough for their use case). Zama uses TFHE, which allows any operation (eg comparisons) with unlimited depth. So if you only need add/mul, BFV, BGV and CKKS are good options. For anything else, you better use TFHE

I was curious about that choice as well. I guess they also just wanted to operate on integers and not floats

Re: Swift Homomorphic Encryption

#116

Post by PROMISE_237 »

GTP wrote: post #111
MBCook wrote: post #36

Earlier quoted context omitted.

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…

AFAIK (but my knowledge is 2/3 years out of date) the problem with general computation is that current schemes are still too slow for parctical use. But recent developments give hope that it could be doable in the future.

[dead]

Re: Swift Homomorphic Encryption

#117

Post by tjade273 »

kmeisthax wrote: post #26
MBCook wrote: post #12

Earlier quoted context omitted.

I tried to look homomorphic encryption up casually earlier this year. I saw references that it was being used, but I don’t think they said where. This is one topic I have a very hard time with, I just don’t know enough math to really grok it. It just seems crazy a system could operate on encrypted data (which is effectively random noise from the server’s point of view) and return a result that is correctly calculated…

Let's say I want you to add two numbers, but I don't want you to know what those numbers are, nor what the result is. What I can do is multiply both numbers by some other number you don't know. I then give you the premultiplied numbers, you add them, and give back a premultiplied answer. I can then divide out the number to get the true result. What we've done here is this: (a * key) + (b * key) = (c * key) The rules…

A set of numbers with addition and multiplication is a _ring_ and is a _field_ only if every nonzero number has a multiplicative inverse.

Integers mod N for composite N (like in RSA) form a ring, not a field - if N = p*q then there is is no well-defined division by `p` or `q` (for example, there is no element corresponding to `2/p`).

When p is prime, every nonzero integer `x` has a multiplicative inverse `1/x` mod p. That's why the integers mod `p` form a field (denoted F_p).

In fact there is another kind of finite field that has `p^n` elements where `p` is any prime and `n` is any positive integer. These fields are not composed of the integers mod p^n, but are made of polynomials of degree `n` with coefficients in F_p.

Re: Swift Homomorphic Encryption

#118

Post by tempay »

fboemer wrote: post #87
tempay wrote: post #49

Earlier quoted context omitted.

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.

Re: Swift Homomorphic Encryption

#119

Post by karulont »

menkalinan wrote: post #113

I don't quite understand how the server can match the ciphertext with a value without knowing the key. How does the server determine that the ciphertext corresponds to the specific value? If the server constructs this ciphertext-value database, how does it know what algorithm to use to create ciphertext from a value and store on its side?

Check my comment here for some intuition: https://news.ycombinator.com/item?id=41115179

Basically the server does not know, it just computes with every possible value. And the result turns out to be what the client was interested in.

Re: Swift Homomorphic Encryption

#120

Post by motohagiography »

j2kun wrote: post #101
motohagiography wrote: post #79

great to see this becoming part of mainstream tools. the question I have is, when a weakness is published in FHE, is it more like a hash function you can do some transformations on, but there is no 'decryption' to recover plaintext again- or is it more like a symmetric cipher, where all your old ciphertexts can be cracked, but now your FHE data sets are no longer considered secure or private and need to be re-generat…

It is more like a symmetric cipher. Once you have a key you can decrypt everything encrypted with that key

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.

Post reply on HN