Hacker News Reader

Comment by eternalban | Hacker News Reader

Here is a short list of the downsides. I’m sure there is more. Tech is always double edged, it seems.

- present false source to claimed binary build of same.

- allow for pervasive backdoors in binary blobs that resist scrutiny by security researchers

I don't think that game developers/media companies/etc care about the two things that you have mentioned. All they want is un-crackable DRM.

Non interactive media will always have the analog hole, no getting around that.

https://en.wikipedia.org/wiki/Analog_hole

iO isn't going to be used in video games for a long time, if ever. For one, even if it had no overhead, it'd completely ruin any optimizations that the devs needed for the game to run in the real world. But likely iO will add a huge overhead, degrading performance by at least a quadratic factor or more. iO also doesn't consider things like syscalls or hardware instructions, which might break the security model anyway.

Video/music DRM wouldn't (couldn't?) change from what it is now: the plaintext bits have to be surfaced to the user at some level (so that it can be displayed/played), so they can simply be ripped at that point.

Not even theoretically possible, as far as I can tell. If iO is protecting your decryption key, then any indistinguishable circuit would also include your decryption key in some form.

I'm having trouble thinking of cases where iO gives you any actual guarantees that matter, because of this property.

If you're interested, check out the paper called "How to Use Indistinguishability Obfuscation" by Sahai and Waters. They were able to prove some very surprising things -- including how to hide a private key by way of iO.

Why would you need to use iO on everything? Wouldn't it be enough to use it on computational inexpensive but vital parts?

I feel like I'm in way over my head here, but how is it even possible to have mathematically uncrackable DRM? Surely at the end it's going to come down to a comparison instruction (or a few thousand of them), no?

So you want to modify those instructions to crack DRM? Which of them? There is a lot of instructions (say, your few thousand) and even more combinations of instructions, you can't find another combination of instructions which would work.

I guess my problem is that I don't see a fundamental difference between this approach and traditional obfuscators/packers/virtualizers/whatever. They can also bloat a simple comparison (for example) into many seemingly useless but interconnected instructions. I just don't understand how it's possible to make a DRM scheme that can't be cracked.

user identification and telemetry come to mind

I think the second one applies but I don't see how indistinguishability obfuscation could allow for the first.

(sorry for late reply.) There was a bit in the OP that said in passing, "[f]or instance, it enables the creation of “deniable” encryption, in which you can plausibly convince an attacker that you sent an entirely different message from the one you really sent".

So candidate plaintexts that are plausible sources for the obfuscated blob appears to be a capability of this approach.

Thanks, now I see the connection.

As there's a whole other thread going on right now about deniable encryption (in the context of e-mail), I think it's worth pointing out that the recipient still typically knows whether or not a particular encryption method is deniable. Such methods would presumably not be a good idea to use for software distribution.

In other words, the deniability is an intentional construction that could be used if parties feel they have a reason to use it (like in a messaging application, as tptacek and Matthew Green are arguing for). However, it's not something that automatically applies to all signature methods merely because of the existence of indistinguishability obfuscation. A software signature method that is constructed to have a deniability property is probably not one that a software user should accept. :-)

In my view, which I've expressed elsewhere, software releases should move in the exact opposite direction by including advertisements of their existence in a public log (whether that's a blockchain, a widely-distributed git repository, a Certificate Transparency log, or whatever).

Reply on news.ycombinator.com