IBM completes successful field trials on Fully Homomorphic Encryption:
Yesterday, Ars spoke with IBM Senior Research Scientist Flavio Bergamaschi about the company's recent successful field trials of Fully Homomorphic Encryption. We suspect many of you will have the same questions that we did—beginning with "what is Fully Homomorphic Encryption?"
FHE is a type of encryption that allows direct mathematical operations on the encrypted data. Upon decryption, the results will be correct. For example, you might encrypt 2, 3, and 7 and send the three encrypted values to a third party. If you then ask the third party to add the first and second values, then multiply the result by the third value and return the result to you, you can then decrypt that result—and get 35.
You don't ever have to share a key with the third party doing the computation; the data remains encrypted with a key the third party never received. So, while the third party performed the operations you asked it to, it never knew the values of either the inputs or the output. You can also ask the third party to perform mathematical or logical operations of the encrypted data with non-encrypted data—for example, in pseudocode, FHE_decrypt(FHE_encrypt(2) * 5) equals 10.
[...] Although Fully Homomorphic Encryption makes things possible that otherwise would not be, it comes at a steep cost. Above, we can see charts indicating the additional compute power and memory resources required to operate on FHE-encrypted machine-learning models—roughly 40 to 50 times the compute and 10 to 20 times the RAM that would be required to do the same work on unencrypted models.
[...] Each operation performed on a floating-point value decreases its accuracy a little bit—a very small amount for additive operations, and a larger one for multiplicative. Since the FHE encryption and decryption themselves are mathematical operations, this adds a small amount of additional degradation to the accuracy of the floating-point values.
[...] As daunting as the performance penalties for FHE may be, they're well under the threshold for usefulness—Bergamaschi told us that IBM initially estimated that the minimum efficiency to make FHE useful in the real world would be on the order of 1,000:1. With penalties well under 100:1, IBM contracted with one large American bank and one large European bank to perform real-world field trials of FHE techniques, using live data.
[...] IBM's Homomorphic Encryption algorithms use lattice-based encryption, are significantly quantum-computing resistant, and are available as open source libraries for Linux, MacOS, and iOS. Support for Android is on its way.
(Score: 2) by FatPhil on Sunday August 02 2020, @09:16PM (12 children)
> For example, you might encrypt 2, 3, and 7 and send the three encrypted values to a third party. If you then ask the third party to add the first and second values, then multiply the result by the third value and return the result to you, you can then decrypt that result—and get 35.
Let's just formulate that as:
D((E(2)+E(3))*E(7)) = 35
By generalisation, this should also be true:
D(E(2)*E(5)) = 10
And later:
> in pseudocode, FHE_decrypt(FHE_encrypt(2) * 5) equals 10.
Or in my syntax:
D(E(2)*5) = 10
So, given the expression: D(x) = 10, we have from the first equation x=E(2)*E(5), and from the second E(2)*5.
I can only conclude that E(5)=5. Wow, so encrypt, much secure.
Lesson: always look at the mathematical papers, or ask for an explanation from someone who understands the principles of the algorithm, and don't rely on popular journalism.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by shortscreen on Sunday August 02 2020, @09:28PM (4 children)
You don't get back 35. You get something which decrypts to 35.
(Score: 2) by FatPhil on Monday August 03 2020, @12:38AM (3 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by coolgopher on Monday August 03 2020, @06:33AM (2 children)
I believe what shortscreen was trying to say is that the third party does not have the knowledge that the resulting blob will decrypt to 35. The third party only knows that it has three ciphertexts, which after performing the requested operations results in a fourth ciphertext.
(Score: 2) by FatPhil on Monday August 03 2020, @06:39AM (1 child)
And it's irrelevant to my point.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Tuesday August 04 2020, @07:52AM
Your point is, regardless, wrong.
There are no claims about density nor 1:1-ness, so nothing says that X != Y implies D(X) != D(Y).
And "by generalization" utterly fails. You need D(E(5) * 2) = D(E(5) * E(2)) for that, which isn't required by this form of homomorphism.
(Score: 1) by anubi on Sunday August 02 2020, @10:55PM (1 child)
I am still a bit confused on why this isn't yet another hash technique.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 3, Informative) by FatPhil on Monday August 03 2020, @12:39AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: -1, Redundant) by Anonymous Coward on Monday August 03 2020, @03:26AM (2 children)
?? I don't understand what you're criticizing. Your example there is wrong, it should be:
> in pseudocode, FHE_decrypt(FHE_encrypt(2) * FHE_encrypt(5)) equals 10. (emphasis mine)
Most of the math in FHE is over my head, but it involves complex data structures. "FHE_encrypt(2) * 5" is an impossible operation because FHE_encrypt(2) results in something more complex than, say, a 4x4 matrix. "FHE_encrypt(2) * 5" would be like saying, "3 * rectangle" or "4x4 matrix + 7" or "325 degrees + 4 liters". It has to be FHE_encrypt(2) * FHE_encrypt(5).
An outside attacker can't just trivially reverse engineer all of the numbers involved.
(Score: 0) by Anonymous Coward on Monday August 03 2020, @04:23AM (1 child)
The statement "In pseudocode, FHE_decrypt(FHE_encrypt(2) * 5) equals 10" is a direct quote from the article.
(Score: 0) by Anonymous Coward on Monday August 03 2020, @11:13AM
Sorry, I missed that. Thanks for the correction.
(Score: 0) by Anonymous Coward on Monday August 03 2020, @08:03AM (1 child)
Because you cannot arbitrarily mix operands that are encrypted and those not encrypted in the homomorphic systems people actually use like that. You cannot have a D(E(2)*5) = 10 equation as the systems won't allow you to do the operations you want for obvious reasons.
(Score: 0) by Anonymous Coward on Tuesday August 04 2020, @07:36AM
I didn't explain that very well. You cannot arbitrarily mix operands of different types in the same operations. So you could have one multiplication operation that allows you to multiply two encrypted values, one that allows you to multiply two clear values, and a third that allows you to multiply one encrypted and one clear operand. This makes it look like you can construct a D(E(2)*E(5)) = 10 and D(E(2)*5) = 10 at the same time, set them equal to each other, and do the elimination you do. But they are not the same operation. Instead you would get something like D(E(2)*1E(5)) = 10 and D(E(2)*35) = 10. When you set them equal to each other, and cancel out the decryption step, you get E(2)*1E(5) = E(2)*35. There is no operation you can do to get E(5) = 5 because the same operation done on both sides to "divide" by E(2) will result in a wrong answer on one side or the other because you used the wrong type of operand.