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

TFHE: Fast Fully-Homomorphic Encryption Over the Torus

tfhe.github.io

Post reply on HN
Print view View original

61–70 of 98 posts

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#61

Post by sandGorgon »

maffydub wrote: post #52
sandGorgon wrote: post #10

Will this be useful for machine learning in the same way as this ? https://medium.com/numerai/encrypted-data-for-efficient-mark...

Open Mined ( http://openmined.org/ ) are looking at this from the other angle - sharing the encrypted neural network with their users so that they can train it without sharing their data at all - the encrypted gradients are computed by the user and collated and decrypted by the company that wants to train the neural network. (Not affiliated in any way, but went to a really interesting talk on this a few weeks ago as…

oh - its very similar to numerai. Pretty cool. I think this is their library - https://github.com/OpenMined/R-Homomorphic-Encryption-Packag... (they havent ported this to python, so are having to use R-bridge to use it in jupyter. I wonder why).

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#62

Post by Bromskloss »

erikpukinskis wrote: post #56
phkahler wrote: post #33

One interesting thing about this: You are performing known operations on unknown data. But theoretically you could simulate a generic computer whose program is encrypted data as well, thus enabling unknown operations on unknown data. However, with speeds in the ms per gate we are a long way from that being practical right now.

> with speeds in the ms per gate I wonder if you could write your programs in such a way that the bulk of the computation was done publically, and only sensitive ops were shunted out to the secure processing network. Maybe in a language similar to Erlang, but instead of writing code that's amenable to sharing between multiple CPUs, you'd be sharing between multiple degrees of privacy.

> I wonder if you could write your programs in such a way that the bulk of the computation was done publically, and only sensitive ops were shunted out to the secure processing network.

Do you have some example of what such an application may be?

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#65

Post by dllthomas »

mikeash wrote: post #53
dllthomas wrote: post #47

Earlier quoted context omitted.

Why would we expect to need a full modern CPU? An 8080 had thousands, and that's still general purpose. Something built for a specific task might well be substantially smaller. Still slow, but possibly realistic for some tasks.

It's a long way from even an 8080. The 8080 had a couple thousand gates and ran at 2+MHz. At 50 gates per second, this would run an 8080 at maybe 20 milli hertz.

Yeah, I didn't mean to imply that it'll happily emulate an 8080 at useful speeds. I wanted to illustrate the orders of magnitude between "minimal something useful" and "a modern cpu", and an 8080 is a reasonably familiar point on that spectrum.

Anything you can do in 10 or 20 cycles of an 8080, you can now do to secret data in a few hours. And you can probably do much, much faster than that if you design a special purpose circuit. It's still sloooow by the computational standards we're used to. But it might be fast enough that there are useful applications.

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#66

Post by mikeash »

dllthomas wrote: post #65
mikeash wrote: post #53

Earlier quoted context omitted.

It's a long way from even an 8080. The 8080 had a couple thousand gates and ran at 2+MHz. At 50 gates per second, this would run an 8080 at maybe 20 milli hertz.

Yeah, I didn't mean to imply that it'll happily emulate an 8080 at useful speeds. I wanted to illustrate the orders of magnitude between "minimal something useful" and "a modern cpu", and an 8080 is a reasonably familiar point on that spectrum. Anything you can do in 10 or 20 cycles of an 8080, you can now do to secret data in a few hours. And you can probably do much, much faster than that if you design a special pu…

Makes sense. I am definitely excited to see something that even vaguely approaches practicality, even if it's a long way from megaflop territory.

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#69

Post by ris »

simcop2387 wrote: post #23
tveita wrote: post #19

Earlier quoted context omitted.

"The library supports the homomorphic evaluation of the 10 binary gates (And, Or, Xor, Nand, Nor, etc…), as well as the negation and the Mux gate." So you'd program it by designing a digital circuit using AND, OR, and NOT gates, somewhat similar to how you would make a circuit with physical components. You have millions, maybe billions of these gates in your CPU, each capable of doing millions of calculations for eac…

I wonder then how implementable this is in an FPGA for accelerating the whole thing? This could be a killer use of the FPGA instances on AWS and similar cloud services.

Well, no, other way around more likely - the most practical way of building programs for these systems would probably be through VHDL/Verilog with a specialized toolchain.

(edit: although actually FPGAs could be useful simply because they can be very good at running FFTs (as are GPUs), not because of the gate-programmable nature of them)

Re: TFHE: Fast Fully-Homomorphic Encryption Over the Torus

#70

Post by mSparks43 »

yorwba wrote: post #41
mSparks43 wrote: post #25

Earlier quoted context omitted.

because the simple fact you can process the data and examine the output reveals untold quantities of information about the key. the known plaintext attack breaks pretty much every crypto system, mix that with statistical analysis of this "processing" and I'm sure whatever is in the cloud will surrender its secrets pretty quick. And all that risk for what benefit? none of this processing will ever be faster than doing…

> And all that risk for what benefit? none of this processing will ever be faster than doing the processing in place. The benefit comes into play when you mix data from different sources that don't trust each other (to the point where they would never agree to one of them doing the processing in place). Homomorphic encryption allows combining the data without ever revealing it to the one doing the computation.

for example?
Post reply on HN