Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Encryption Intel United States

DARPA Taps Intel To Help Build the Holy Grail of Encryption (techrepublic.com) 54

The Defense Advanced Research Projects Agency, or DARPA, has signed an agreement with Intel to add it to its Data Protection in Virtual Environments project, which aims to create a practically useful form of fully homomorphic encryption. From a report: Fully homomorphic encryption has been described as the "holy grail" of encryption because it allows encrypted data to be used without ever having to decrypt it. Fully homomorphic encryption isn't fantasy -- it already exists and is usable, but it is incredibly impractical. "FHE adoption in the industry has been slow because processing data using fully homomorphic encryption methods on cryptograms is data intensive and incurs a huge 'performance tax' even for simple operations," Intel said in a press release.

The potential benefits of fully homomorphic encryption make creating a practical way to use it a cybersecurity imperative. Intel succinctly describes the biggest problem in data security as being caused by "encryption techniques [that] require that data be decrypted for processing. It is during this decrypted state that data can become more vulnerable for misuse." The goal of the Data Protection in Virtual Environments program is to develop an accelerator for fully homomorphic encryption that will make it more practical and scalable, which is where Intel comes in. The chip manufacturer's role in the project will be academic research and the development of an application-specific integrated circuit that will accelerate fully homomorphic encryption processing. Intel said that, when fully realized, its accelerator chip could reduce processing times by five orders of magnitude over existing CPU-driven fully homomorphic encryption systems.

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

DARPA Taps Intel To Help Build the Holy Grail of Encryption

Comments Filter:
  • by darkain ( 749283 ) on Monday March 08, 2021 @02:28PM (#61137464) Homepage

    How long until THIS one melts down!?

  • Comment removed based on user account deletion
  • Why not just pick 5-10 celebrity cryptographers, give them 100 million, and actually get a better result in the end?

    • by gtall ( 79522 )

      Because we already know how to do homomorphic encryption. Now it is a computation problem. When in doubt, throw more hardware at it. Intel probably could do a good job with it. However, if it was such a munchy nugget, how is it they need DARPA funds to do it?

      Now every chip designer will be racing to be up first at bat to beat Intel. Which company wants to be beholden to Intel if they can avoid it?

    • That assumes theoretical breakthroughs are to be had.

      If doing the same old thing faster is cheating, but a 1e5 speedup is attainable, hey, let's cheat.

    • So you think 5-10 cryptographers are the best people to do silicon and chip design? interesting, do you get celebrity chefs to advise you on farming techniques and celebrity influencers to design your smart phone camera lens?
    • We don't need cryptographers, we need people able to figure out what to do with it. Like many other "holy grails of encryption", this one has about as much real (not imagined) practical use as tits on a bull.
  • how is that not the same as not being encrypted? Sorry for my ignorance, but I read the attached article, and would like to know a simple explanation of how this works, and is still safe from snooping?
    • I think ROT13 is a form of homomorphic encryption: you can process the contents without ever having to decrypt them as a whole (just add 13 to each character before printing it!).

      Now if only someone could develop a chip able to add 13 to every character going through it... That's where Intel's extensive expertise comes in!!!!

    • So, if you have two encrypted numbers, a and b, with homomorphic encryption, you can do operations on them like a + b = c. You still don't know what a, b or c is but you can pass c back to the person who has the encryption key and they can read it.

    • by BeerFartMoron ( 624900 ) on Monday March 08, 2021 @03:00PM (#61137598)

      I want to use a cloud service like AWS to host my application, but I don't trust AWS to not read my data. So I encrypt my data before storing it in AWS. Right now, in order to feasibly process and manipulate that encrypted data, I first need to decrypt it. If I could instead process and manipulate that encrypted data in the cloud without ever decrypting it, that would be the Holy Grail.

      • you assume it will be available to non-corporate entities (such as individuals) or governments ? Even the supreme-progressive marshlands government in holland is moving against encryption-for-the-plebs (too many molotov-mongrels i suppose fucking it up for everyone) so if THEY have a key as a backdoor then the fancy bears and the koreans will certainly have one too - as will Iran and 15 years later the hackers-on-meth ...
        with the highest respect for personal privacy we feel its necessary to be able to sca
    • The idea is that you can't read it while it's encrypted but you can work on it while it's encrypted. So imagine you could take an encrypted data set, perform an operation on it, get an encrypted result, and decrypt that to see what the result is without the computer that did the operation ever having access to the decrypted data at all. That would be an example of homomorphic encryption. In a sufficiently advanced form this could let you do something like run a VM on a computer that could not get data out o

    • by spitzak ( 4019 )

      The idea is that the calculation produces an encrypted result from the encrypted input. Apparently that is mathematically possible. A trivial example: say your encryption xor's the input data with a key-generated pattern. You can easily compute the xor of the data with any constant, producing the encrypted result, by doing the same xor to the encrypted data.

      I do wonder exactly what operations are permitted by this. It would seem like any operation that changes the size of the data based on it's value would

      • I do wonder exactly what operations are permitted by this. It would seem like any operation that changes the size of the data based on it's value would not be allowed as checking the resulting size would leak information about the data.

        A very accessible introduction to the subject is, Computing Arbitrary Functions of Encrypted Data [stanford.edu] by Craig Gentry, at the time, of IBM's T.J. Watson Research Center.

      • >I do wonder exactly what operations are permitted by this.

        In one system, Yao Garbled Circuits, and the more efficient derivatives can model basic logic gates. You need to build you algorithm from those things.

         

    • A functioning FHE algorithm will be able to do a computation on your computer. You will be able to see every operation, every bit, every transition. But you will not be able to determine the data values.

      The details are not simple. You can look up "Yao Garbled Circuits" for a classic example of such a scheme. This maps your algorithm to logic primitves (ands, ors, nots) and then replaces each logic gate with (if I remember right) 6 block cipher operations. That's around 90,000 factor increase in compute
      effor

    • Every reply here says why and what for. And not a single one says HOW. Which is what OP asked.

      Seems we got the curent crop of college finishers here. Confusing memorized patterns with actual understanding.
      They will make great MS support hotline workers and code monkeys. ;)

      • by tlhIngan ( 30335 )

        Every reply here says why and what for. And not a single one says HOW. Which is what OP asked.

        That's because homomorphic encryption is hard. It was only a few years ago that it was proven that it was possible to do any operation you want if the cipher meets certain requirements.

        Then it was to prove a cipher meeting those requirements was still secure and not have an inadvertent backdoor.

        Then it was to find such a cipher. We know of many homomorphic ciphers that allowed for limited operations - there were on

    • Its called compartmentalization. A cell can read and process information and send it back. It does not work, and registers/memory is only as good at the physical compartment.
  • Until they can break it, and then they can sell it as the Next Big Thing®

  • by jmccue ( 834797 ) on Monday March 08, 2021 @02:48PM (#61137540) Homepage

    Does that include a backdoor like Intel ME ?

  • So, does that mean 2^5 (32x) or 10^5 (100000x)?

  • Fully homomorphic encryption isn't fantasy -- it already exists and is usable, but it is incredibly impractical

    FHE has existed for a while but what it really does is generate a series of logical operations that execute on a virtual machine of sorts, while keeping everything encrypted. The problem is that it is so slow that it cannot be used for anything. FHE is the ultimate DRM (impossible to read, only possible to execute), so it's no wonder it's desired.

    Businesses would see FHE instructions as a panacea to keep their secrets but the reality is that antivirus would become all but impossible. It would be buyer's

    • This also allows host-proof computing--you can execute code on cloud servers without revealing the data, and decrypt it on-prem.

    • FHE has existed for a while but what it really does is generate a series of logical operations that execute on a virtual machine of sorts, while keeping everything encrypted.

      In the simplest form, you take encrypted data and perform a series of multiplies and additions. These each have an equivalent effect of acting as a logic gate on the input value(s). Thus, you construct your typical VM of these gates, translated back to adds and multiplies. The issue here is that the numbers get extremely large, extremely quickly, as you may imagine. Thus, a large chunk of the problem is scaling those values back into a workable range every so often (or using a more advanced method than this

    • No it is useless as DRM.

      What good is a movie, if you can never watch it?

      Watching it ALWAYS requires decryption and sending signals to a display unit to light up lights. Wheter you put a CCD on top of the OLED or you just open it and grab the signals going to the LEDs, you will always end up with a unprotected uncompressed signal that you can compress and copy at will.

      Also, what good is thar snake oil, even if it would work as hallicinated, if nobody's willing to let the obsolete Content Mafia steal from the

      • No it is useless as DRM.

        What good is a movie, if you can never watch it?

        spoken like a fool who doesn't understand neither HFE nor DRM.

    • It is slow, but if it could be sped up, there's a potential market for it. The idea is that companies like Microsoft, IBM, etc. that have massive data centers could store your encrypted data and process it for you without having to decrypt it at any point which doesn't open the possibility of that decrypted data being exposed. Even the processed results are encrypted so they're meaningless to whoever did the processing.

      All it really does is allow companies that have data that they want or need to keep pr
    • but the reality is that antivirus would become all but impossible. It would be buyer's remorse from day one of widespread FHE instruction adoption.

      Stop being homomorphicphobic.

  • if it were only for putting some thinfilm solar sheet on the barn.
    Or any other of those holy grails that we have been chasing for the past decades.

  • I do not pretend to understand homomorphic encryption, but the promise of manipulating information while encrypted sound a lot like the anonymity features of David Chaums DigiCash system. Can anyone confirm the similarities and/or explain why this is (totally) different?
  • You have two alternatives for where to invest new hardware:
    1. Use additional hardware to make computation more secure, but not faster.
    2. Use additional hardware to make computation faster, but not more secure (except where additional speed offers additional security).
    As long as there's a need for additional speed, I can't see anyone going for option 1.

    Of course, this path led us to Spectre and Meltdown, so perhaps the decision isn't always so cut and dried.
    But excepting big flaws like that, I don't see this

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Working...