Live data from Hacker News

TFHE: Fast Fully-Homomorphic Encryption Over the Torus

tfhe.github.io

71–80 of 98 posts

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

#71
post #45
post #22

Earlier quoted context omitted.

My first guess would be conditionals, but I'd guess there is no real branching in the execution of operations on data. Another would be evaluating comparisons, but those aren't very easy to do in bitwise terms, and you can't read the output either.

But the thing about this setting is that you don't possess the secrets, so you can't reveal the secrets by noticing how long things take. An analogy to think about might be blind signatures. In blind signatures you sign a blinded token and then the other party can unblind it to get a valid signature from you over a message whose content you don't know. This is classical public-key cryptography. In that case there is…

so whats the "cloud-keyset " then?

the "side channel" i am referring to is in however this impliments this mixing you refer to.

if you can observe how the internal state is changing given a cloud keyset you should be able to infer the secret key. in the same way you can infer the iv used in a mesernine twister from like 27 cycles (or whatever).

downvotes and promises definately wont reduce my skeptacism.

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

#72

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…

> the known plaintext attack breaks pretty much every crypto system This isn't true at all.

aside from aes and its varients, which of the other thousands of crypto systems arent vulnerable to it?

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

#73
post #51
post #31

Earlier quoted context omitted.

There are applications for it, despite the speed penalty.

What are those applications?

Any application where you need an untrusted third party to do operations on encrypted data, without them getting access to the data itself.

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

#74

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…

You can examine the output and so on, but that's not a side-channel attack, which is what I was responding to. And yes, it is a malleable cryptosystem, but that doesn't imply you can learn the key from an input/output pair, nor does it imply you can read the input given to you. It just means you can change the output in a way that can still be decrypted by the same key. Usually people use padding and IVs and such to…

you dont need to get the key, you just need to decrypt the data.

they do not need to be one in the same, if, statistically you can infer input given output.

And i never said sure in any way shape or form. what i said is i am skeptical of the motivations driving a project like this, when we know for an absolute fact bad men are trying to steal our secrets. It seems like a lot of work and very heavy math for something that will never tip the balance that is holding the cloud back with people not trusting it to keep their secrets.

for example, if you can do something as simple as compute a hash of the unencrypted data, you can instantly decrypt all data with known hashes with a high degree of certainty, without ever knowing the keys - side channel attack.

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

#75

That's a seriously cool thing to have in the toolbox! Does it produce only encrypted output, or can it optionally produce unencrypted results also? Can it optionally use public data as an input? Also I am guessing if it could be accelerated on GPUs. I worked with a guy who accelerated a standard FFT on CUDA 100..1000 times for scientific computations (and later NVidia copied his code, lol). I wonder if something simi…

The point is to be able to give encrypted data to a third party and have them do operations on that data (ex. sum all the values) and give you an encrypted result back. tldr. computations in the cloud with encrypted, private data

because, obviously, summing all the values is something you couldnt do yourself?

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

#76

That's a seriously cool thing to have in the toolbox! Does it produce only encrypted output, or can it optionally produce unencrypted results also? Can it optionally use public data as an input? Also I am guessing if it could be accelerated on GPUs. I worked with a guy who accelerated a standard FFT on CUDA 100..1000 times for scientific computations (and later NVidia copied his code, lol). I wonder if something simi…

> This work leaves much room for improvement, however. For example, the throughput and latency can be significantly improved by using GPUs and FPGAs to accelerate the computation. https://www.microsoft.com/en-us/research/wp-content/uploads/... > We demonstrate CryptoNets on the MNIST optical character recognition tasks. CryptoNets achieve 99% accuracy and can make more than 51000 predictions per hour on a single PC.…

Oh wow! I didn't ask for the last one, but this is insanely interesting also!

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

#77
post #6

This looks very interesting! However, not being an expert on FHE, is there a way to leverage this on current RDBMS systems for example? It says the library can evaluate binary gates. If we would like to run a SQL query for example, how do we translate it to a series of gates? Is it possible? Or is this so low level that we basically would need to build our own "processor" with binary gates and then build the rest of…

https://www.youtube.com/watch?v=xsaXMUelOEA "CryptDB: Processing Queries on an Encrypted Database - Microsoft Research"

TFHE is not even in the same galaxy as CryptDB. Comparing the two is like comparing an apple and a 2007 Honda Civic. They're polar opposite approaches to executing queries on encrypted databases.

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

#78
post #6

This looks very interesting! However, not being an expert on FHE, is there a way to leverage this on current RDBMS systems for example? It says the library can evaluate binary gates. If we would like to run a SQL query for example, how do we translate it to a series of gates? Is it possible? Or is this so low level that we basically would need to build our own "processor" with binary gates and then build the rest of…

I would apply it instead of garbled circuits here https://eprint.iacr.org/2016/591 . Although slower, it feels like TFHE would provide better security against an active adversary. So, at least, simple server-side encrypted queries would well be possible

Can you explain how you would use FHE instead of garbled circuits in the Arx range query data structure? I don't see how that would work - wouldn't you have to (re-)introduce interaction to let the server learn intermediate results?

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

#79
post #73
post #51

Earlier quoted context omitted.

What are those applications?

Any application where you need an untrusted third party to do operations on encrypted data, without them getting access to the data itself.

Right but that's nearly tautological...I meant specific applications that can tolerate the massive performance sacrifice.

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

#80

Earlier quoted context omitted.

> the known plaintext attack breaks pretty much every crypto system This isn't true at all.

aside from aes and its varients, which of the other thousands of crypto systems arent vulnerable to it?

None of the other AES finalists were vulnerable to known plaintexts attacks. Neither is 3-DES or chacha20. DES and RC4 are now considered insecure, but in their day they were resistant known plaintext attacks as well.

Other than some toy examples, and cryptosystems that were used before cryptography was studied academically, I can't think of any that are vulnerable to known plaintext attacks.

Post reply on HN