1. Hopes, fears, and software obfuscation
- Author
-
Boaz Barak
- Subjects
General Computer Science ,Computer science ,business.industry ,Plaintext ,Cryptography ,0102 computer and information sciences ,02 engineering and technology ,Software obfuscation ,Encryption ,Computer security ,computer.software_genre ,01 natural sciences ,Authentication (law) ,Field (computer science) ,Software ,010201 computation theory & mathematics ,020204 information systems ,Obfuscation ,0202 electrical engineering, electronic engineering, information engineering ,business ,computer - Abstract
I survey some of the recent progress on software obfuscation spurred by the exciting paper of Garg, Gentry, Halevi, Raykova, Sahai and Waters [GGH13]. This is a preprint version of a review article [Bar16] appearing in the Communications of the ACM. That article was written for a general computing audience, and is also not up to date on the latest research in this fast-moving field since it was mostly written in 2014. Nevertheless, I thought it might still be of interest to cryptographers. Computer programs are arguably the most complex objects ever constructed by humans. Even understanding a 10-line program such as the one depicted in Figure 1 can be extremely difficult. The complexity of programs has been the bane (as well as the boon) of the software industry, and taming it has been the objective of many efforts in industry and academia. Given this, it is not surprising that both theoreticians and practitioners have been trying to “harness this complexity for good” and use it to protect sensitive information and computation. In its most general form this is known as software obfuscation, and it is the topic of this survey. In a certain sense, any cryptographic tool such as encryption or authentication can be thought of harnessing complexity for security, but with software obfuscation people have been aiming for something far more ambitious: a way to transform arbitrary programs into an “inscrutable” or obfuscated form. By this we don’t mean that reverse engineering the program should be cumbersome but rather that it should be infeasible, in the same way that recovering the plaintext of a secure encryption cannot be performed using any reasonable amount of resources. ∗Harvard John A. Paulson School of Engineering and Applied Sciences, b@boazbarak.org. This article was written while the author was at Microsoft Research
- Published
- 2016