Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fully homomorphic encryption and the dawn of a private internet

bozmen.io

Post reply on HN
Print view View original

81–90 of 202 posts

Re: Fully homomorphic encryption and the dawn of a private internet

#81

Post by reliabilityguy »

blintz wrote: post #3

I say this as a lover of FHE and the wonderful cryptography around it: While it’s true that FHE schemes continue to get faster, they don’t really have hope of being comparable to plaintext speeds as long as they rely on bootstrapping. For deep, fundamental reasons, bootstrapping isn’t likely to ever be less than ~1000x overhead. When folks realized they couldn’t speed up bootstrapping much more, they started talking…

Even without bootstrapping FHE will never be as fast as plaintext computation: the ciphertext is about three orders of magnitude much larger than the plaintext data it encrypts, which means you have to have more memory bandwidth and more compute. You can’t bridge this gap.

Re: Fully homomorphic encryption and the dawn of a private internet

#82

Post by niclas-183 »

perlgeek wrote: post #63

FHE might allow arbitrary computation, but I use most services because they have some data I want to use: their search index, their knowledge, their database of chemicals, my bank account transactions, whatever. So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it. The other point is incentives: outside of some…

Exactly what I thought. In the end it really isn't in most of the big corps interest to not see your data/query. They need/want to see it so why would they degrade their ability to do so if they can just say no and you will have to rely on using their services without FHE. For banking applications cool, everyone else debatable if it will ever be accepted.

Re: Fully homomorphic encryption and the dawn of a private internet

#83

Post by perching_aix »

swores wrote: post #77
perching_aix wrote: post #73

Earlier quoted context omitted.

I can appreciate if someone doesn't (or if most people don't, even) see the fun in this, sure. > Considering the first mile would need to have been faster than 23mph That said, note that it's not just the up-leg's average speed that's been provided (15 mph), but also the distance as you say (1 mile). If you explore the error term for both of these, you'll see that it's not necessary to go at the ludicrously high spee…

If you go as far as assuming the mile distance is wrong then the entire question is pointless, maybe they've already travelled more than two miles and they need to go backwards to average 30mph! At that point literally any number is just as correct as 41 is...

It does allow for making any number between 40.833546516585657030783661635542 (exact) and ∞ work, 41 just being the lowest whole number that works. Travelling backwards, being arbitrarily wrong, or any arbitrary number working doesn't fit these new constraints still, however.

Re: Fully homomorphic encryption and the dawn of a private internet

#84

Post by asah »

blintz wrote: post #3

I say this as a lover of FHE and the wonderful cryptography around it: While it’s true that FHE schemes continue to get faster, they don’t really have hope of being comparable to plaintext speeds as long as they rely on bootstrapping. For deep, fundamental reasons, bootstrapping isn’t likely to ever be less than ~1000x overhead. When folks realized they couldn’t speed up bootstrapping much more, they started talking…

Thx! I'm curious about your thoughts...

- FHE for classic key-value stores and simple SQL database tables?

- the author's argument that FHE is experiencing accelerated Moore's law, and therefore will close 1000x gap quickly?

Thx!

Re: Fully homomorphic encryption and the dawn of a private internet

#85

Post by throwaway478484 »

NoImmatureAdHom wrote: post #80
drcolly wrote: post #51

Earlier quoted context omitted.

The statements made in the linked description of this cannot be true, such as Google not being able to read what you sent them and not being able to read what they responded with. Having privacy is a reasonable goal, but VPNs and SSL/TLS provide enough for most, and at some point your also just making yourself a target for someone with the power to undo your privacy and watch you more closely- why else would you go t…

> The statements made in the linked description of this cannot be true, such as Google not being able to read what you sent them and not being able to read what they responded with. The beautiful thing is: they are :-)

If Google’s services can respond to queries, they must be able to read them.

If A uses a cereal box cipher and B has a cereal box cipher, B can can make sense of encoded messages A sends them, A can ask about the weather, and B can reply with an encoded response that A can decode and read. B is able to read A’s decoded query, and B knew what the weather was, and responded to A with that information.

Security is not magic.

Re: Fully homomorphic encryption and the dawn of a private internet

#86

Post by ElFitz »

yorwba wrote: post #66
ElFitz wrote: post #34

Earlier quoted context omitted.

> Now it looks to me that the whole input must be encrypted with key k. But in the search example, the inputs include a query […] and a multi-terabyte database […] That’s not the understanding I got from Apple’s CallerID example[0][1]. They don’t seem to be making an encrypted copy of their entire database for each user. [0]: https://machinelearning.apple.com/research/homomorphic-encry... [1]: https://machinelearning…

They do not explicitly state this fact, but they link to the homomorphic encryption scheme they're using, which works like this. To perform an operation between a plaintext value and an encrypted value, you first encrypt the plaintext with the public key and then you can do your operation on the encrypted values to get the encrypted output. Moreover, even if the details were slightly different, a scheme that reveals…

Is that what they mean in the Wally paper post by

> In previous private search systems, for each client query, the server must perform at least one expensive cryptographic operation per database entry.

?

Re: Fully homomorphic encryption and the dawn of a private internet

#87

Post by Tryk »

littlecranky67 wrote: post #27
barisozmen wrote: post #24

Earlier quoted context omitted.

You can reduce anything happening on the computer to arithmetic operations. If you can do additions and multiplications, then it's turing complete. All others can be constructed from them.

While correct, that doesn't answer the question at all, though. If I have my address book submited into an FHE system and want to sort by name - how do you do that if the FHE system does not have access to cleartext names?

When comparing two ciphertexts A,B a FHE sorting function will output a sorted pair of two new ciphertexts:

E.g. FHE_SORT(A,B) -> (X,Y)

where Dec(X)But without decoding, there's no way of knowing whether X (or Y) comes from A or B.

Source: II. D of https://eprint.iacr.org/2015/995.pdf

Re: Fully homomorphic encryption and the dawn of a private internet

#88

Post by reliabilityguy »

strangecasts wrote: post #46
utf_8x wrote: post #37

As someone who knows basically nothing about cryptography - wouldn't training an LLM to work on encrypted data also make that LLM extremely good at breaking that encryption? I assume that doesn't happen? Can someone ELI5 please?

Good encryption schemes are designed so that ciphertexts are effectively indistinguishable from random data -- you should not be able to see any pattern in the encrypted text without knowledge of the key and the algorithm. If your encryption scheme satisfies this, there are no patterns for the LLM to learn: if you only know the ciphertext but not the key, every continuation of the plaintext should be equally likely,…

I am confused: you can implement LLM learning with FHE. It’s a different problem than learning on encrypted data.

Re: Fully homomorphic encryption and the dawn of a private internet

#89

Post by dismalpedigree »

kube-system wrote: post #23
haiku2077 wrote: post #12

Earlier quoted context omitted.

You're not joking. If you're like most people and have only a few TiB of data in total, self hosting on a NAS or spare PC is very viable. There are even products for non-technical people to set this up (e.g. software bundled with a NAS). The main barrier is having an ISP with a sufficient level of service.

Sure, hardware is cheap. However if you actually follow the 3-2-1 rule with your backups, then you need to include a piece of real estate in your calculation as well, which ain’t cheap.

I have true 3-2-1 backups on a server running proxmox with 32 cores, 96gb of ram, and 5TB of ssd disks (2TB usable for VMs). Cost me $1500 for the new server hardware 2 years ago. Runs in my basement and uses ~30w of power on average (roughly $2.50/mo). The only cloud part is the encrypted backups at backblaze which cost about $15/mo.

Its a huge savings over a cloud instance of comparable performance. The closest match on AWS is ~$1050/mo and I still have to back it up.

The only outage in 2 years was last week when there was a hardware failure of the primary ssd. I was back up and running within a few hours and had to leverage the full 3-2-1 backup depth, so I am confident it works.

If i was really desperate i could have deployed on a cloud machine temporarily while i got the hardware back online.

Re: Fully homomorphic encryption and the dawn of a private internet

#90

Post by hoppp »

bawolff wrote: post #78
hoppp wrote: post #74

Earlier quoted context omitted.

Its like, python can be 400 times slower than C++, but people still use it.

Yeah, because people use python when it doesn't matter and c++ when it does (including implicitly by calling modules that are backed by c implementations). That is not an option with FHE. You have to go all in.

Yes but with FHE it also depends on the use-case and how valuable the output is and who is processing it and decrypting the final output.

There are plenty of viable schemes like proxy re-encryption, where you operate on a symmetric key and not on a large blob of encrypted data.

Or financial applications where you are operating on a small set of integers, the speed is not an issue and the output is valuable enough to make it worth it.

It only becomes a problem when operating FHE on a large encrypted dataset to extract encrypted information. The data extracted will need to offset the costs. As long as companies don't care about privacy, this use-case is non-existent so its not a problem that its slow.

For military operations on the other hand, it might be worth the wait to run a long running process

Post reply on HN