4 ms·

does this mean that unbreakable DRM will now be possible?

by jonahx 13y ago

pornel 13y ago
Is there anything that prevents running such program in a VM?
VLM 13y ago
No, but it does mean you could technically create a ridiculously more complicated scheme, which means they'll probably be more ways than ever to break it, dumb system design choices, etc. Also more patents will tie things up and create more artificial limits. (If I were more of a jerk, I'd probably be filing an internet era/style patent along the lines of "I now patent the XOR... in functional encryption") The net effect is probably slightly weaker DRM. I read some of the paper. Maybe an intro before you even read the paper's intro would be a wikipedia article like this: http://en.wikipedia.org/wiki/Functional_encryption http://en.wikipedia.org/wiki/Functional_encryption And a blog post about a similar problem that doesn't work from about a decade ago like this: http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html The 2001 paper TLDR is something like, there exists at least some hash functions that can't be obfuscated. Don't flame me too hard, there's a reason the paper is longer than eleven words. That probably gives enough background to understand the intro to the paper? As you can see by list list of authors in the paper Boaz coauthored, Sahai has been involved in this for a long time and this has been researched and pondered for a long time. Maybe this is way too gross of a summary of the paper, but if you think of how unix filesystem permission bit masks work, you can already do something of that complexity with crypto keys (basic boolean stuff) but the paper proves you can run more complicated "programs" in the crypto key (not just basic boolean, but access_level >= 5 or whatever). Another relatively ancient crypto concept that you probably need as a background is at least an understanding of what SSSS can do. Maybe not how it works, but the idea that keys can be screwed around with other than just one unitary thing. Being stuck with the analogy in head that a crypto key maps 1:1 with the idea of a physical tumbler lock key isn't helping too much... well maybe unless you start thinking about master keys and stuff like that. Maybe another awful TLDR analogy, this time of the 2013 paper, is I can make at a system level a powered smartcard that executes arbitrary code to do all kinds of stuff with and around a key .... as per the paper at the algorithm level (not the system level) you could execute arbitrary code in the key. Which brings us back to the original DRM topic that smartcards have not been all that successful in the crypto world (insert debate here) so being able to "do computin'" in an algorithm rather than a chunk of slightly tamper resistant hardware probably isn't going to be much different for the endusers. And it'll be a lovely tasty new patent minefield. So I wouldn't expect much if any DRM impact.
gizmo686 13y ago
No. This result says nothing about DRM.

does this mean that unbreakable DRM will now be possible?

by jonahx 13y ago

does this mean that unbreakable DRM will now be possible?

pornel 13y ago

Is there anything that prevents running such program in a VM?

VLM 13y ago

No, but it does mean you could technically create a ridiculously more complicated scheme, which means they'll probably be more ways than ever to break it, dumb system design choices, etc. Also more patents will tie things up and create more artificial limits. (If I were more of a jerk, I'd probably be filing an internet era/style patent along the lines of "I now patent the XOR... in functional encryption") The net effect is probably slightly weaker DRM. I read some of the paper. Maybe an intro before you even read the paper's intro would be a wikipedia article like this: http://en.wikipedia.org/wiki/Functional_encryption http://en.wikipedia.org/wiki/Functional_encryption And a blog post about a similar problem that doesn't work from about a decade ago like this: http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html http://www.cs.princeton.edu/~boaz/Papers/obf_informal.html The 2001 paper TLDR is something like, there exists at least some hash functions that can't be obfuscated. Don't flame me too hard, there's a reason the paper is longer than eleven words. That probably gives enough background to understand the intro to the paper? As you can see by list list of authors in the paper Boaz coauthored, Sahai has been involved in this for a long time and this has been researched and pondered for a long time. Maybe this is way too gross of a summary of the paper, but if you think of how unix filesystem permission bit masks work, you can already do something of that complexity with crypto keys (basic boolean stuff) but the paper proves you can run more complicated "programs" in the crypto key (not just basic boolean, but access_level >= 5 or whatever). Another relatively ancient crypto concept that you probably need as a background is at least an understanding of what SSSS can do. Maybe not how it works, but the idea that keys can be screwed around with other than just one unitary thing. Being stuck with the analogy in head that a crypto key maps 1:1 with the idea of a physical tumbler lock key isn't helping too much... well maybe unless you start thinking about master keys and stuff like that. Maybe another awful TLDR analogy, this time of the 2013 paper, is I can make at a system level a powered smartcard that executes arbitrary code to do all kinds of stuff with and around a key .... as per the paper at the algorithm level (not the system level) you could execute arbitrary code in the key. Which brings us back to the original DRM topic that smartcards have not been all that successful in the crypto world (insert debate here) so being able to "do computin'" in an algorithm rather than a chunk of slightly tamper resistant hardware probably isn't going to be much different for the endusers. And it'll be a lovely tasty new patent minefield. So I wouldn't expect much if any DRM impact.

gizmo686 13y ago

No. This result says nothing about DRM.