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

101–110 of 135 posts

Re: Swift Homomorphic Encryption

#101

Post by j2kun »

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

Re: Swift Homomorphic Encryption

#103

Post by ElFitz »

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…

> I had thought homomorphic encryption could be used to do actual calculations, at least certain kinds.

Well yes. There was this:

- https://news.ycombinator.com/item?id=21638639

- https://news.ycombinator.com/item?id=31933995

- https://azeemba.com/posts/homomorphic-encryption-with-images...

And quite a few more.

Re: Swift Homomorphic Encryption

#104

Post by nmadden »

hansvm wrote: post #91
nmadden wrote: post #54

Earlier quoted context omitted.

Right, but IND-CCA1 is kind of a toy security goal though. A sort theoretical consolation prize if you can’t achieve the real thing. And AFAICT, no actually implemented schemes do obtain even CCA1?

Sure, but that's "how much security you're sacrificing to get the FHE goodness," and, as always in crypto systems, implementations might not be that good. > A sort theoretical consolation prize if you can’t achieve the real thing The real thing exists largely because it makes proofs easier. For something like FHE you can bolt on some extra user-space features to build something like IND-vCCA (your decryption oracle r…

> The real thing exists largely because it makes proofs easier.

I would not say that. It exists because practical padding oracle attacks (which are adaptive CCA) have been known for decades. CCA2 very much captures real-world attacks. Is there any realistic attack that is captured by CCA1? (Or vCCA).

Padding oracle attacks also generalise to any kind of parsing after decryption. Padding tends to be studied because it is independent of any particular format/application and also part of several encryption scheme definitions. The definition of CCA2 captures very realistic scenarios - almost all applications do some parsing after decryption and so are quite likely to reveal an oracle. Would vCCA also capture such attacks?

Re: Swift Homomorphic Encryption

#105

Post by Jommi »

fboemer wrote: post #86
GTP wrote: post #50

Earlier quoted context omitted.

Is the used scheme fully homomorphic encryption or just homomorphic wrt a specific operation? Because they only mention "homomorphic" without the "fully".

Swift Homomorphic Encryption implements the Brakerski-Fan-Vercauteren (BFV) HE scheme ( https://eprint.iacr.org/2012/078 , https://eprint.iacr.org/2012/144 ) (without bootstrapping). This is a leveled HE scheme, which supports a limited number of encrypted adds and multiplies (among other operations). [Disclosure: I work on the team responsible for the feature]

That’s awesome. I’m part of a cryptography group working on more applied uses of homomorphic encryption, is there a way to contact you?

Re: Swift Homomorphic Encryption

#106

Post by dllthomas »

tempay wrote: post #30
dllthomas wrote: post #27

Earlier quoted context omitted.

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 in…

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…

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

Re: Swift Homomorphic Encryption

#107

Post by kybernetikos »

yalogin wrote: post #92

FHE is cool but I wonder how many use cases it actually fits. Don’t get me wrong, it gives better security guarantees for the end user but do they really care if the organization makes a promise about a secure execution environment in the cloud? Also from an engineering point of view, using FHE requires a refactoring of flows and an inflexible commitment to all processing downstream. Without laws mandating it, do org…

I think the main thing that throws it into question is when you get the software that sends the data to the service and the service from the same people (in this case apple). You're already trusting them with your data, and a fancy HE scheme doesn't change that. They can update their software and start sending everything in plain text and you wouldn't even realise they'd done it.

FHE is plausibly most useful when you trust the source of the client code but want to use the compute resource of an organisation you don't want to have to trust.

Re: Swift Homomorphic Encryption

#108

Post by MzxgckZtNqX5i »

nmadden wrote: post #104
hansvm wrote: post #91

Earlier quoted context omitted.

Sure, but that's "how much security you're sacrificing to get the FHE goodness," and, as always in crypto systems, implementations might not be that good. > A sort theoretical consolation prize if you can’t achieve the real thing The real thing exists largely because it makes proofs easier. For something like FHE you can bolt on some extra user-space features to build something like IND-vCCA (your decryption oracle r…

> The real thing exists largely because it makes proofs easier. I would not say that. It exists because practical padding oracle attacks (which are adaptive CCA) have been known for decades. CCA2 very much captures real-world attacks. Is there any realistic attack that is captured by CCA1? (Or vCCA). Padding oracle attacks also generalise to any kind of parsing after decryption. Padding tends to be studied because it…

While it might not provide a direct answer to your question, this paper could be an interesting read: https://eprint.iacr.org/2021/1624.

Re: Swift Homomorphic Encryption

#110

Post by rhindi »

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

Post reply on HN