Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Google Open Source Encryption

Google Open-Sources Fully Homomorphic Encryption (FHE) Toolkit (therecord.media) 78

Google has open-sourced a collection of C++ libraries for implementing Fully Homomorphic Encryption (FHE) in modern applications. From a report: Fully homomorphic encryption, or simply homomorphic encryption, is a form of data encryption that allows users/applications to perform mathematical computations on encrypted data without decrypting it first, keeping the data's privacy intact. While the concept of homomorphic encryption has been around since 1978, when it was first described at a theoretical level, and 2009, when it was first implemented in practice, it has not been broadly adopted in software due to its complexity, advanced cryptography techniques, and lack of open-source code and public documentation. However, despite this, today, FHE is a hot technology in software design.

FHE allows software vendors to work on encrypted data without sharing the encryption/decryption keys with untrustworthy systems such as client-side apps or publicly-hosted web servers, where the keys could be stolen or intercepted by malware or malicious human operators. FHE allows developers to keep data secure, encrypted, and private, all at the same time, and Google hopes that developers will use its FHE libraries as the first step into adopting this new type of encryption technology within their applications.

This discussion has been archived. No new comments can be posted.

Google Open-Sources Fully Homomorphic Encryption (FHE) Toolkit

Comments Filter:
  • Hey . . (Score:5, Funny)

    by Joey Vegetables ( 686525 ) on Friday June 18, 2021 @07:20AM (#61498526) Journal
    I'm homomorphophobic, you insensitive clod!
    • You may be joking, but it would make sense to be homomorphoic encryption phobic. This essentially means that malware can perform fully encrypted computation on your system using your CPU time. There is no way to know what data is being processed or what type of processing is being applied. This instantly brings to mind a bittorrent-esque malware network that is entirely impossible to identify or protect against; all blended in with an uncountable number of secret processes executed on encrypted data.

      Such pr

      • OK, showing my ignorance here I guess, but how is that different from the current situation?
        • That depends upon the capability of the user to disassemble or decompile machine code executed on their platforms and the complexity of the web of dynamic libraries involved. So from a practical standpoint I'll admit there is no difference - however - from the point of view of a security researcher or anyone doing any reverse engineering this is a nightmare.
          • OK. That seems fair.

            As an aside regarding reverse engineering and why it's more necessary than it used to be:

            I've been doing software development for a long time. In the past, we used to write, test, and deploy our own code, using libraries only when truly appropriate and only when fully understood, since we were ultimately responsible for the result. Lately, however, with the rise of Framework Oriented Programming, we basically glue other people's code together until it sort of works, then hope that bit

  • It is also dead slow (Score:5, Interesting)

    by gweihir ( 88907 ) on Friday June 18, 2021 @07:59AM (#61498566)

    The main problem remaining is that this is dead slow. That makes it more something of theoretical interest, because any data transformations protected this way will need to do more than just a few simple steps to be of any value and then things will take forever.

    Don't get me wrong, FHE is a great and fundamental theoretical result. But its practical applications are rather limited and usually get vastly overstated.

    • Yes, but I imagine the idea is to use dedicated hardware to speed things up. There will always be a penalty, just a lessor of one.

      • by gweihir ( 88907 )

        Yes, but I imagine the idea is to use dedicated hardware to speed things up. There will always be a penalty, just a lessor of one.

        I know that. The penalty will always be extreme here though.

    • Can someone explain this screenshot from the git repo's examples,
      where the operation is a simple CapitalizeString(),
      and the "Total Time" is 0.7 seconds (capitalizing just 30 characters or so!)
      but the "CPU Time" is 46 seconds.

      https://raw.githubusercontent.... [githubusercontent.com]

      • by bws111 ( 1216812 )

        Explain what? Yes, it is slow, nobody is claiming otherwise. As for CPU time vs total time, they parallelized the operation over a bunch of CPUs. 64 CPUs working for .7 seconds would be about 45 seconds of CPU time.

        • by gweihir ( 88907 )

          This also gives a nice example of the performance. Capitalizing 30 chars on a modern CPU should be in the area of less than 1us. This takes around 50'000'000 times longer.

    • by Tom ( 822 )

      There are some applications where you're dealing with highly sensitive data, and throwing more CPU power at the problem to do it like this is cheaper than setting up an entire dedicated system with hardening, strict auditing, secure interfaces etc.

      And, you know, a few CPU generations down the line, what seems theoretical today is merely a bit expensive then.

      • by gweihir ( 88907 )

        There are some applications where you're dealing with highly sensitive data, and throwing more CPU power at the problem to do it like this is cheaper than setting up an entire dedicated system with hardening, strict auditing, secure interfaces etc.

        Unlikely. Because the amount of data you can realistically process is tiny.

        And, you know, a few CPU generations down the line, what seems theoretical today is merely a bit expensive then.

        Nope. The mathematics does not allow that. Also. CPUs have basically hit a wall performance-wise about 5-10 years ago.

      • by flux ( 5274 )

        I think you don't appreciate how slow this is.

        It seems the computers would need to be around 2^30 times as fast as they are now to do the string capitalization task as fast as current computers can do locally. So, assuming Moore's Law holds (this task seems to be suitable for parallelization), that's around half a century.

  • Code Link (Score:5, Informative)

    by Some Guy ( 21271 ) on Friday June 18, 2021 @08:13AM (#61498586)
    A link to the actual code since the post doesn't include it: https://github.com/google/full... [github.com]
  • TFA should have just linked to this:
    https://github.com/google/full... [github.com]

    Personally I don't have a need for this and don't see much of a point of running code on systems you don't trust. Add to that security of these systems rely on the untrusted server faithfully executing a given code and value prop gets a little weird.

    Nonetheless the idea and concepts are interesting themselves and transpiler makes it easier to use than I assumed it would be. Sum/calc examples in github literally just define functions that

  • I've had several training classes from seemingly highly competent individuals claiming Homomorphic Encryption can be used to park your data in the cloud and allow you to use their tools to search, index, etc to optimize your data yet keep the cloud provider from being able to see the data.

    I've argued (and from this description, rightfully so) that if their tools can read your data, they can read your data, extract it, provide it to governments, or anything else they want.

    They are trying to sell this tech to

  • by FeelGood314 ( 2516288 ) on Friday June 18, 2021 @11:28AM (#61498956)
    I will use it when I create a database in the cloud and need to do queries on the data but don't want the cloud provider to know what the data is or what my query is. I will use it for voting tabulation where everyone can see the votes, everyone can tabulate and verify the results but no one can see how an individual votes. I'm not going to use FHE for processing your medical records or any single large record in the cloud, at least not anytime soon.

    I think the first use for this will be password and other login information storage. I will keep your Credit card info, username and password in the cloud and my cloud provider won't know who's information I have stored but I can query this database for say users who's accounts will expire next month.
    • Why? You don't need HME for this? Existing encryption methods work just fine. For passwords you can use one-way encryption. For the credit cards, just use asymmetric encryption where you retain the key, download the record in question, and verify it. The point of HME is to operate on large data sets not individual records.
      • by tlhIngan ( 30335 )

        Why? You don't need HME for this? Existing encryption methods work just fine. For passwords you can use one-way encryption. For the credit cards, just use asymmetric encryption where you retain the key, download the record in question, and verify it. The point of HME is to operate on large data sets not individual records.

        No, the point of HME is to perform computations on database records without decrypting the data.

        Let's say you have a database of employees. Naturally, it's encrypted because ransomware and

        • That all sounds good. And this isn't my area of expertise. And I hate to argue with the "hot, new" thing. There are clearly *some* useful HME operations but there are also operations that are not HME. i.e. I want to provide an employee self-service portal to update their mailing address. I need to pre-fill it with their address. So I need to retrieve...and decrypt it. So now I have some HME operations and some non-HME operations which means I have increased (not decreased) my attack surface. I can s
  • by gus goose ( 306978 ) on Friday June 18, 2021 @11:42AM (#61498996) Journal

    IBM released their FHE code first https://www.ibm.com/security/s... [ibm.com]

    https://developer.ibm.com/solu... [ibm.com]

    Reported here on Slashdot as well
    https://developers.slashdot.or... [slashdot.org]

  • Does that mean using it will turn me gay? Asking for a friend.

  • I thought this was 2021. Get with the times.
  • That's one sure way to kill it. Quick! Name a product or technology that wasn't killed by Google open sourcing it. Yes, Kubernetes is in that category, too. Google is just god awful at pushing tech, even good tech. Golang? Dead. And it's actually a good language.

"What the scientists have in their briefcases is terrifying." -- Nikita Khrushchev

Working...