3 ms·

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.

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

csunbird 6y ago
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.
- kaszanka 6y ago
  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?
  - avmich 6y ago
    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.
    - kaszanka 6y ago
      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.
- aruss 6y ago
  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.
  - sterlind 6y ago
    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.
    - aruss 6y ago
      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.
  - anotheryou 6y ago
    Why would you need to use iO on everything? Wouldn't it be enough to use it on computational inexpensive but vital parts?
- m463 6y ago
  user identification and telemetry come to mind
- p1necone 6y ago
  Non interactive media will always have the analog hole, no getting around that. https://en.wikipedia.org/wiki/Analog_hole https://en.wikipedia.org/wiki/Analog_hole
schoen 6y ago
I think the second one applies but I don't see how indistinguishability obfuscation could allow for the first.
- eternalban 6y ago
  (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.
  - schoen 6y ago
    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).

csunbird 6y ago

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.

kaszanka 6y ago
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?
- avmich 6y ago
  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.
  - kaszanka 6y ago
    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.
aruss 6y ago
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.
- sterlind 6y ago
  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.
  - aruss 6y ago
    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.
- anotheryou 6y ago
  Why would you need to use iO on everything? Wouldn't it be enough to use it on computational inexpensive but vital parts?
m463 6y ago
user identification and telemetry come to mind
p1necone 6y ago
Non interactive media will always have the analog hole, no getting around that. https://en.wikipedia.org/wiki/Analog_hole https://en.wikipedia.org/wiki/Analog_hole

schoen 6y ago

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

eternalban 6y ago
(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.
- schoen 6y ago
  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).