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

91–98 of 98 posts

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

#91

Post by enigma83 »

mSparks43 wrote: post #71
schoen wrote: post #45

Earlier quoted context omitted.

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.

The "cloud keyset" is another name for "public key". Usually, public key enables encryption but no decryption, here, the cloud key enables computations on ciphertexts, but not decryption.

Like in public key cryptography, you can give a RSA public key to an adversary, he can use it as much as he want, he will not be able to get any information on the private key (in any practical time). Most importantly, the cloud key is not secret, nor obfuscated: the cloud already knows each bits of it (side channel attacks are not relevant).

The "cloud key" is the public part of the key given to the cloud so that he can perform his operations (circuit, bootstrapping). There are strong security proofs that show that it is impossible to recover the secret key from the cloud key.

In the case of TFHE, if there was a polynomial algorithm that would recover even a single bit of the secret key given the cloud key, this algorithm could be used to break the LWE problem, and also worst case instances of lattice problems (which are much harder than factorization or discrete log for instance).

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

#92

Post by enigma83 »

mSparks43 wrote: post #74
striking wrote: post #43

Earlier quoted context omitted.

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…

In homomorphic encryption, the cloud performs operations on encrypted data, and gets only an encrypted result. He does not have any information on the decrypted result.

That's the difference between FHE and IO or multilinear maps. The second ones are almost all broken, mostly because of the attacks you mention. FHE, on the other hand, has semantic security.

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

#93

Post by jacobush »

SilasX wrote: post #28
striking wrote: post #16

Earlier quoted context omitted.

"Each binary gate takes about 20 milliseconds single-core time to evaluate" So yes, for varying definitions of "fast".

If you equate a binary gate operation with an instruction, then that's 50 instructions per second, which compares to UNIVAC's 2000 IPS (0.002 MIPS). https://en.wikipedia.org/wiki/Instructions_per_second#Timeli... Of course, an op on a single bit is still far short of a CPU instruction, AIUI. You gotta start somewhere though!

So a cluster of modern cores could approach a UNIVAC...

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

#94

Post by nicpoulos »

lkowalcz wrote: post #34
proofofstake wrote: post #29

Earlier quoted context omitted.

Yes, but not to the same degree. Numerai uses structure-preserving encryption / neural encryption. This allows people to use any existing machine learning algorithm on the data. For fully homomorphic encryption you would need specialized algorithms. These are way more difficult to design. They also run slower.

Worth pointing out that Numerai actually doesn't use encryption in any standard sense (including structure-preserving encryption), but instead seems to be using some heuristic method of obfuscating their data. Their (closed-source) method of obfuscating their data apparently does have the property that it preserves the structure of the data, but calling it "structure-preserving encryption" is misleading imo since it…

This is a great and really important point. But shouldn't warranting the "encryption" label come down to the security guarantee of the algorithm in question, in the use cases it's meant for? I don't see why non-traditional data obfuscation algorithms can't be equally valid methods of "encryption" just because they are architecturally different. After all there are plenty of traditional encryption approaches that have been deprecated and deemed insufficiently insecure. So it'd be a bigger problem if the definition of encryption became so narrow that practitioners assume security guarantees based on use of the term alone.

IMO the key is that new encryption methods demonstrate levels of security in their intended use cases that users deem sufficiently strong. I agree that all closed-source methods leave room for misleading statements (and I won't speak to Numerai as I don't have any additional insight on their approach). But any algorithm can and should be benchmarked--generally and vs. common standards--to avoid confusion. Serious commercial & public sector users will be quick to ensure so, especially in lieu of massive social proof.

My thought here is that if we draw the line on what warrants "encryption" by saying it's got to be a traditional key-based system, or sufficiently similar to existing approaches, we risk stifling innovation in the space by denying new entrants an industry-standard term that buyers are trained to seek. Non-traditional doesn't necessarily mean non-secure. Would love to hear your thoughts on this.

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

#95

Post by lkowalcz »

nicpoulos wrote: post #94
lkowalcz wrote: post #34

Earlier quoted context omitted.

Worth pointing out that Numerai actually doesn't use encryption in any standard sense (including structure-preserving encryption), but instead seems to be using some heuristic method of obfuscating their data. Their (closed-source) method of obfuscating their data apparently does have the property that it preserves the structure of the data, but calling it "structure-preserving encryption" is misleading imo since it…

This is a great and really important point. But shouldn't warranting the "encryption" label come down to the security guarantee of the algorithm in question, in the use cases it's meant for? I don't see why non-traditional data obfuscation algorithms can't be equally valid methods of "encryption" just because they are architecturally different. After all there are plenty of traditional encryption approaches that have…

I think it's appropriate to restrict usage of the word "encryption" to methods that come with some justification for their security.

I don't think that doing this stifles innovation (In fact, I think requiring crypto innovations to have security justifications is probably better overall for innovation in the field)

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

#96

Post by ris »

kevin_thibedeau wrote: post #90
ris wrote: post #69

Earlier quoted context omitted.

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)

HDLs have no special advantage in evaluating boolean operations in simulation. Most simulators are significantly slower than native code unless they use compiler infrastructure used by mainstream languages and even then they still have the penalty of maintaining the simulation environment which serves no purpose in this application.

Is is not simply that the best way we have of describing complex systems made out of logic gates is with these languages?

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

#97

Post by kevin_thibedeau »

ris wrote: post #96
kevin_thibedeau wrote: post #90

Earlier quoted context omitted.

HDLs have no special advantage in evaluating boolean operations in simulation. Most simulators are significantly slower than native code unless they use compiler infrastructure used by mainstream languages and even then they still have the penalty of maintaining the simulation environment which serves no purpose in this application.

Is is not simply that the best way we have of describing complex systems made out of logic gates is with these languages?

They don't describe logic gates directly. They are used to formulate boolean expressions which are mapped into gates or an equivalent structure by synthesis software. Outside of special circumstances, no one is manually crafting individual gates when writing with an HDL. that is left to the back end tooling. If the target isn't hardware then normal programming languages are just as good. There is no magic speedup when HDLs are simulated and you just pay the penalty of keeping track of simulated time and sequencing of events that don't matter if you just want to compute an answer.

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

#98

Post by nicpoulos »

lkowalcz wrote: post #95
nicpoulos wrote: post #94

Earlier quoted context omitted.

This is a great and really important point. But shouldn't warranting the "encryption" label come down to the security guarantee of the algorithm in question, in the use cases it's meant for? I don't see why non-traditional data obfuscation algorithms can't be equally valid methods of "encryption" just because they are architecturally different. After all there are plenty of traditional encryption approaches that have…

I think it's appropriate to restrict usage of the word "encryption" to methods that come with some justification for their security. I don't think that doing this stifles innovation (In fact, I think requiring crypto innovations to have security justifications is probably better overall for innovation in the field)

Your specific statement was valid and good-natured, so I didn't mean to attack you here. All I'm arguing against is the adoption of a legal or de-facto definition of "encryption" based on architectural similarity to currently popular methods, rather than actual evaluation in situ. Most all practical applications of crypto trade security for functionality to some extent, and requirements for one or the other vary based on the use case. Future security gains, moreover, won't likely all be made on traditional grounds (e.g. increased susceptibility to brute force hacks). That's why I'm hesitant to support statements like "X company is misleading us by using the term 'encryption' because its closed-source approach doesn't appear to adhere to conventional notions on cursory inspection."

Much practical innovation comes from closed-source applications whose peer review comes in the form of commercial lab tests. Overly ossified technology standards & labels often force CIOs / CTOs / CISOs to build artificial barriers into their corporate procurement processes for optical reasons. In addition to engendering "check-the-box" complacency, these barriers absolutely stifle startup-driven innovation.

Post reply on HN