A New Design for Cryptography’s Black Box • Hacker News Board

Re: A New Design for Cryptography’s Black Box

#11

Post by venomsnake » Mon, Sep 14, 2015, 5:52 AM UTC

munin wrote: post #6

derefr wrote: post #4

Earlier quoted context omitted.

To expand on that: what the article is basically talking about is "DRM that actually works"—the ability to send someone some encrypted data embedded in a wrapper program. You can run the wrapper program and interrogate it all you like on its own terms—but other than satisfying the desire of the wrapper program's code-paths, there's no way to get decrypted data out. If the data is dumb content like text, this amounts…

There are "good" and "bad" uses for this technology. Bad uses: Netflix will put their video stuff into this and now you will never jack content from their software. Good uses: Your IM and email can live in this and no compromise of your host operating system can leak your information. Your computer can be hacked by every hacker on Earth simultaneously and your secrets are safe.

> Netflix will put their video stuff into this and now you will never jack content from their software.

Yep. It is good I cannot record what is on the screen. Or in the video buffer.

Re: A New Design for Cryptography’s Black Box

#12

Post by aruss » Mon, Sep 14, 2015, 5:56 AM UTC

We've come a long way since the first IO result came out. Since then, we've gotten a couple more multilinear map candidates (though most are now broken), and some simpler constructions, but we're still really far from IO with a proof. This is primarily because of the underlying multilinear map that's being used. The Gentry et al result that proves IO secure in the generic multilinear model isn't that useful yet simply because there have been so many nongeneric attacks against mmap candidates, especially when they're used in IO. That is, at the moment there's no reason to believe that the generic multilinear model is even a good way to think about IO security.

What would be a really big result is finding IO that doesn't rely on multilinear maps.

Re: A New Design for Cryptography’s Black Box

#13

Post by Animats » Mon, Sep 14, 2015, 6:14 AM UTC

0x0 wrote: post #2

Is this about data encryption, or is it about hiding the inner workings of an executable binary (malware packing/copy protection)?

The last time I saw this, the idea was to fully unwind a program into a huge, very deep, loop-free network of logic gates. After that, it was possible to create an larger network which produced the same outputs for the same inputs, but with internal structure obfuscated in a way that was theoretically difficult to undo. This was a interesting concept, but didn't immediately lead anywhere useful. Has there been progress?

Re: A New Design for Cryptography’s Black Box

#14

Post by drdeca » Mon, Sep 14, 2015, 6:54 AM UTC

userbinator wrote: post #7

munin wrote: post #3

Earlier quoted context omitted.

what's the difference? ;)

The short answer is "only in how it is used". Security is a double-edged sword. You can use it to protect against others, and others can also use it to protect against you. As computer security becomes stronger, I think it could be almost irresponsible to only mention the "good" uses - hackers accessing your bank account seems to be the cliche example - without also mentioning the malware-hiding, user-hostile, locked…

for malware hiding, you could avoid that by demanding that the programs contain mathematical proofs that they do not do a certain number of malicious things, or that they only do a particular non-malicious thing?

Re: A New Design for Cryptography’s Black Box

#15

Post by dexterdog » Mon, Sep 14, 2015, 11:33 AM UTC

derefr wrote: post #9

eximius wrote: post #8

Earlier quoted context omitted.

It still only takes 1 person with legitimate access to share it. DRM is always defeatable.

The "real honest-to-god TPM" I was talking about? That would also be the basis for a DCCP-like system that actually worked indefinitely. Communications between your device and your display would be encrypted with keys that aren't extractable from the memory of either. Of course, the signal is going to end up decrypted at the DAC interface, and you can always capture it there. But that doesn't give you the original en…

So then you use two unique captures of the same material to find the deltas and munge away.

Re: A New Design for Cryptography’s Black Box

#16

Post by ingenter » Mon, Sep 14, 2015, 12:21 PM UTC

I'd like to note that IO does not give a guarantee of impossibility of extracting keys.

AFAIK, the definition of IO is: we have two programs that perform the same computation. After we apply IO to both programs, we cannot figure out which obfuscated program corresponds to a particular original program.

However, there is a flaw: programs encrypting data with different keys are performing different computations.

So IO definition does not claim that IO is able to hide the key.

Re: A New Design for Cryptography’s Black Box

#17

Post by phkahler » Mon, Sep 14, 2015, 1:44 PM UTC

ingenter wrote: post #16

I'd like to note that IO does not give a guarantee of impossibility of extracting keys. AFAIK, the definition of IO is: we have two programs that perform the same computation. After we apply IO to both programs, we cannot figure out which obfuscated program corresponds to a particular original program. However, there is a flaw: programs encrypting data with different keys are performing different computations. So IO…

>> So IO definition does not claim that IO is able to hide the key.

From what I've read, that doesn't even matter. The obfuscated program IS effectively the key. A copy of that obfuscated program is still a copy of the key. It's still not clear to me what the advantage is supposed to be.

Re: A New Design for Cryptography’s Black Box

#18

Post by tromp » Mon, Sep 14, 2015, 2:17 PM UTC

phkahler wrote: post #17

ingenter wrote: post #16

I'd like to note that IO does not give a guarantee of impossibility of extracting keys. AFAIK, the definition of IO is: we have two programs that perform the same computation. After we apply IO to both programs, we cannot figure out which obfuscated program corresponds to a particular original program. However, there is a flaw: programs encrypting data with different keys are performing different computations. So IO…

>> So IO definition does not claim that IO is able to hide the key. From what I've read, that doesn't even matter. The obfuscated program IS effectively the key. A copy of that obfuscated program is still a copy of the key. It's still not clear to me what the advantage is supposed to be.

The obfuscated program only uses its embedded key in ways it sees fit. You cannot sign arbitrary statements with the key.

Re: A New Design for Cryptography’s Black Box

#19

Post by aruss » Mon, Sep 14, 2015, 8:39 PM UTC

ingenter wrote: post #16

I'd like to note that IO does not give a guarantee of impossibility of extracting keys. AFAIK, the definition of IO is: we have two programs that perform the same computation. After we apply IO to both programs, we cannot figure out which obfuscated program corresponds to a particular original program. However, there is a flaw: programs encrypting data with different keys are performing different computations. So IO…

Your initial thought is why most people believed there to be little use in IO other than maybe removing software watermarks and the like. But this idea of a "punctured program" came around in which you can place the key in the program in a very clever way such that you get a security proof about hiding the key in the obfuscated program.

It turns out we can do just about anything in modern crypto using IO - it is an extremely powerful primitive - including symmetric encryption, public-key encryption, etc.

Re: A New Design for Cryptography’s Black Box

#20

Post by dogma1138 » Tue, Sep 15, 2015, 12:12 AM UTC

drdeca wrote: post #14

userbinator wrote: post #7

Earlier quoted context omitted.

The short answer is "only in how it is used". Security is a double-edged sword. You can use it to protect against others, and others can also use it to protect against you. As computer security becomes stronger, I think it could be almost irresponsible to only mention the "good" uses - hackers accessing your bank account seems to be the cliche example - without also mentioning the malware-hiding, user-hostile, locked…

for malware hiding, you could avoid that by demanding that the programs contain mathematical proofs that they do not do a certain number of malicious things, or that they only do a particular non-malicious thing?

No you can't, because you can't define what is malicious.

Your partner going through your underwear drawer is perfectly fine. However if you see a stranger doing the same well, its about time to call the cops.