text: Protecting source code against reverse engineering and theft is an important problem. The goal is to carry out computations using confidential algorithms on an untrusted party while ensuring confidentiality of algorithms. This problem has been addressed for Boolean circuits known as circuit privacy'. Circuits corresponding to real-world programs are impractical. Well-known obfuscation techniques are highly practicable, but provide only limited security, e.g., no piracy protection. In this work, we modify source code yielding programs with adjustable performance and security guarantees ranging from indistinguishability obfuscators to (non-secure) ordinary obfuscation. The idea is to artificially generate misleading' statements. Their results are combined with the outcome of a confidential statement using encrypted . Thus, an attacker must guess' the encrypted selector variables to disguise the confidential source code. We evaluated our method using more than ten programmers as well as pattern mining across open source code repositories to gain insights of (micro-)coding patterns that are relevant for generating misleading statements. The evaluation reveals that our approach is effective in that it successfully preserves source code confidentiality.
  @cite_19: In this work, we study indistinguishability obfuscation and functional encryption for general circuits: Indistinguishability obfuscation requires that given any two equivalent circuits @math and @math of similar size, the obfuscations of @math and @math should be computationally indistinguishable. In functional encryption, ciphertexts encrypt inputs @math and keys are issued for circuits @math . Using the key @math to decrypt a ciphertext @math yields the value @math but does not reveal anything else about @math . Furthermore, no collusion of secret key holders should be able to learn anything more than the union of what they can each learn individually. We give constructions for indistinguishability obfuscation and functional encryption that supports all polynomial-size circuits. We accomplish this goal in three steps: (1) We describe a candidate construction for indistinguishability obfuscation for @math circuits. The security of this construction is based on a new al...
  @cite_15: The recent result of (FOCS 2013) changed the previously pes- simistic attitude towards general purpose cryptographic obfuscation. Since their first candidate construction, several authors proposed newer and newer schemes with more persuasive security arguments and better eciency. At the same time, indistinguishabil- ity obfuscation proved its extreme usefulness by becoming the basis of many solutions for long-standing open problems in cryptography e.g. functional or witness encryption and others. In this survey, we give an overview of recent research, focusing on the theoretical results on general purpose obfuscation, particularly, indistinguishability obfuscation. IMPORTANT NOTE: This version of the manuscript not yet includes some new re- sults! Until the next update the reader is advised to check these as well (see page 24)!
summary: Circuit Privacy: Traditional program obfuscation attempts disguise the computation (of a circuit) in one way or another. For instance, Indistinguishability obfuscation requires that given any two equivalent circuits @math and @math of similar size, the obfuscations of @math and @math should be computationally indistinguishable @cite_19 . In functional encryption @cite_19 , ciphertexts encrypt inputs @math , and keys are issued for circuits @math . Using a key to decrypt a ciphertext @math , yields the result of the circuit @math evaluated for @math but does not reveal anything else about @math . Furthermore, no collusion of secret key holders should be able to learn anything more than the union of what they can each learn individually. Since the introduction of these concepts @cite_19 , significant progress has been made (see @cite_15 for an overview). We argue that from a practical perspective, encryption at the source (or byte) code level is more meaningful than for Boolean circuits due to performance reasons. Given a processor supports @math commands each implemented using circuits of size @math , it suffices to hide the command type rather than the circuit.