Remove Plagiarism

Running head: A TURING MACHINE SYSTEM FOR SECURE FUNCTION EVALUATION 1

A TURING MACHINE SYSTEM FOR SECURE FUNCTION EVALUATION 11

Project Proposal

A Turing Machine System for Secure Function Evaluation

Student’s Name

Institution Affiliate

Abstract

The amount of data encrypted in this evaluation Algorithms for computing on encrypted data is a fundamental building block of cryptography. The way one models such algorithms has a crucial effect on the efficiency and usefulness of the resulting cryptographic schemes. As of today, almost all known schemes for fully homomorphic encryption, functional encryption, and garbling schemes work by modelling.

Algorithms acts as circuits rather than as Turing machines. As a consequence of this modelling, we will give an evaluation of an algorithm over encrypted data as a slow as the worst-case running time of that algorithm, a direct fact for many tasks. In addition, in settings where an evaluator needs a description of the algorithm itself in some “encoded” form, the cost of computing and communicating such encoding is as large as the worst-case running time of this algorithm.

In this project proposal, we construct cryptographic schemes for computing Turing machines on encrypted data that avoid the worst-case problem. Specifically, we show: An attribute-based encryption scheme for any polynomial-time Turing machine and Random Access Machine (RAM). A functional encryption scheme for any polynomial-time Turing machine. A reusable garbling scheme for any polynomial-time Turing machine. These three schemes have the property that the size of a key or of a garbling for a Turing machine is very short: it depends only on the description of the Turing machine and not on its running time. Previously, the only existing constructions of such schemes were for depth-d circuits, where all the parameters grow with d our constructions which remove this depth d restriction, have short keys, and moreover, avoid the worst-case running time.

Keywords: Computing on encrypted data; Functional encryption; fully homo- morphic encryption; Turing machines; Input-specific running time.

Introduction

A domain-specific language (DSL) is a computer language specialised to a particular application domain. This is in contrast to a general-purpose language, which is broadly applicable across domains. There are a wide variety of DSLs used by Turing machines in evaluation ranging from widely used languages for common domains, such as HTML for web pages, down to languages used by only one or a few pieces of software, such as the soft code. DSLs can be sub-divided by the kind of language, and include domain-specific mark-up languages, domain-specific modelling languages and domain-specific programming languages. Special-purpose computer languages have always existed in the computer age, but the term "domain-specific language" has become more popular due to the rise of domain-specific modelling. Simpler DSLs, particularly ones used by a single application, are sometimes informally called mini-languages.

Literature review

The line between general-purpose languages in giving in evaluation and domain-specific languages is not always sharp, as a language may have specialized features for a particular domain but be applicable more broadly, or conversely may in principle be capable of broad application but in practice used primarily for a specific domain. For example, Perl was originally developed as a text-processing and glue language, for the same domain as AWK and shell scripts, but was mostly used as a general-purpose programming language later on. By contrast, PostScript is a Turing complete language, and in principle can be used for any task, but in practice is narrowly used as a page description language.

Almost all known cryptographic constructions for computing on encrypted data model algorithms as circuits instead of Turing machines. The most notable such constructions are fully homomorphic encryption, attribute-based encryption, functional encryption, and garbling schemes. There are at least two unfortunate consequences of modelling algorithms as circuits (Badrinarayanan & Winch’s, 2018). The first consequence of using circuits is that evaluating an algorithm on encrypted data is at least as slow as the worst-case running time of algorithm on all inputs of a certain size. Ideally, the runtime of

A On input Y Should be the time X takes to run on Y.

This slowdown is due to that all the known transformations from Turing machines to circuits work by unrolling loops to their worst-case runtime, and by considering all branches of a computation. Even if the cryptographic overhead of these schemes were zero, such worst-case runtime can still make the computation slow: e.g. the simplex algorithm for linear programming runs in polynomial time on most instances one encounters in practice, but in exponential time on rare inputs. Some schemes for computing on encrypted data (such as functional encryption and garbling schemes) require the evaluator to obtain a token for an algorithm B in order to run B on the encrypted data. The second consequence of modelling algorithms as circuits is that the size of the token is as large as the running time of the algorithm, instead of depending only on the description of the algorithm, which can be shorter. The earliest example of using circuits for computing on encrypted data is Yao’s

Secure function evaluation protocol (Yao86). This takes as input any polynomial time computable function f specified by a circuit and outputs a “garbled circuit” with the same input-output functionality.

More recent constructions for computing on encrypted data also use circuits to model computation and thus suffer from the worst-case slowdown. In this work, we construct cryptographic schemes for Turing machines, thus removing the two major limitations of circuits discussed above. We construct attribute-based encryption, single-key (succinct) functional encryption, reusable garbling schemes, and a version of FHE for polynomial-time Turing machines. For each of these schemes, we show that the time to evaluate a Turing machine M on an input x is input specific: it depends on the runtime of M on x and not on the worst-case runtime of M on all inputs of length n where n =| x |. Moreover, we show that the token an evaluator needs to run a Turing machine M on encrypted data is short: its size depends on the size of the description of the Turing machine M and not on M’s runtime. Our schemes are for 1 an exception is the garbling scheme of (LO12) for RAMs, but this scheme also suffers from worst-case running time problem.

Both uniform and non-uniform Turing machines (so in particular, they can compute any circuits). Since the evaluator can compute a Turing machine M in input-specific runtime, it means that the evaluator necessarily learns the runtime of M on specific inputs. In some of the schemes we consider, such as ABE, such runtime provides no new information to the evaluator. In other schemes, such as FE, the evaluator could learn additional information from the runtime. This is why we also provide a second functional encryption scheme that does not leak the runtime and runs in worst-case time, while still benefiting from the Turing machine model because it has short tokens. Depending on how one weighs leaking runtime versus worst-case performance, one can choose one scheme or the other. Our schemes are based on extractable witness encryption, a variant of the witness encryption notion of Garg

et al. (GGSW13). We show how to obtain such an extractable witness encryption scheme using the construction of Garg et al.(GGSW13), by strengthening their assumption with a knowledge property. We prove the new assumption secure in the generic group model. Interestingly, we show that extractable witness encryption is closely related to (weakly) on fusc table point-filter functions (GK05).

Traditional garbling schemes are one-time: they are secure only if an adversary gets a token for at most one input. A reusable garbling scheme is secure when the adversary gets an unbounded number of tokens. In known garbling schemes (even non-reusable ones), the size of the garbling is as large as the worst-case runtime of F. Often, the reason is that programs are modelled as circuits, and the size of the garbling is at least the size of the corresponding circuit. In this work, we construct a (reusable) garbling scheme for (uniform or non-uniform) Turing machines, where the size of the garbling depends only on the size of the Turing machine, and is independent of its runtime. The work of (LO12) is an exception from the Circuit model: they model computation as RAM, but their scheme still has large garbling size, at least as large as the worst-case running time. As in our FHE and FE schemes, if one allows leaking the runtime of M on input x, we can additionally avoid worst-case evaluation time and obtain an input-specific reusable garbling scheme: given a garbling for a Turing machine M and a token taken as x, the time to compute M (x) is polynomial in the runtime of M on the specific input x.

Goldwasser bounded circuits; our schemes remove the depth dependency, provide short garbling size, and can additionally avoid worst-case running time. Therefore, there exists a reusable garbling scheme and an input-specific reusable garbling scheme for (uniform or non-uniform) polynomial-time Turing machines from the expectations. In summary, our work models reckoning on encrypted data as Turing machines and thus avoids the worst-case “curse” for a set of well-known cryptographic concepts.

Our Assumptions

Our schemes rely on two assumptions: extractable bystander encryption and the actuality of SNARKs. Extractable Witness Encryption base on the recent exertion of Garg et al., which constructs a new primitive called witness encryption (WE). Such a scheme is associated with some NP complete dialectal. Given an instance x and a message m, any user can encrypt m with respect to x; this is denoted by Enc x (m). Given Enc x (m) and a valid witness w of x, any user can decrypt x proficiently. On the other hand, if x is not in the language, the scheme provides semantic safekeeping (W. Henecka & I. Wehrenberg, 2010). In our work, we additionally assume that turning machine scheme is extractable: if an antagonist can break semantic security for an instance x, an extractor can extract the witness for x. Such an extractable scheme can be constructed from an extractable variety of the assumption. However, we can strengthen their assumption based on the model of evaluation encrypted while we state our assumption in a decisional form for straightforwardness, the search version of the assumption suffices for our schemes because we can use hard-core establishes to mask the one bit we care to hide (m).

We can as well validate our supposition in the generic group model: we prove that no polynomial time adversary can break the assumption in the generic group model where adversaries can only use multilinear map processes as a black-box. We refer the reader to our full paper for more details on the assumption, and highlight that we view our result as a reduction from any extractable witness encryption scheme, as opposed to a result that is tied to the specific computational assumption. We show that, interestingly, extractable witness encryption is highly connected to another task that was already well-known in the cryptographic non-fiction: (weakly) our point-filter functions is defined by Goldwasser and Kalai. Informally, point-filter functions for a language NP with witness relation R L are a class of functions which needs clear evaluation in our appraisal.

Results and Analysis of Turing Machines in Secure Function Evaluation

A variant of fully homomorphic encryption scheme for Turing machines, where one can evaluate a Turing machine M on an encoded input x in time that is dependent on the running time of M on input x as opposed to the worst-case runtime of M. Previously, such a result was known only for a restricted class of Turing machines and it required an expensive pre-processing phase (with worst-case runtime); our structures remove both boundaries. Our results are obtained with respect to a reduction from SNARKs evaluation and an “extractable” variant of bystander encryption, a scheme introduced by Garg et al. We prove that the new assumption is secure in the generic group model. We also point out the connection between (the variant of) witness encryption and the fasciation of point filter functions as defined by Goldwasser and Kalai in 2005.

The Design and Implementation

Domain-specific languages are languages often declared as syntaxes or grammar and with very specific goals in design and execution. A domain-specific language can be one of a visual diagramming language, such as those created by the Generic Eclipse Modelling System, programmatic concepts, such as the Eclipse Modelling Framework, or textual languages. For instance, the command line utility group has a regular appearance syntax which matches patterns in lines of text. The sled utility defines a syntax for corresponding and replacing regular expressions. Often, these tiny languages can be used together inside an explosive to perform more complex software design tasks.

The line between domain-specific languages and scripting languages is somewhat blurred, but domain-specific languages often lack low-level functions for filesystem access, interposes control, and other functions that characterize full-featured programming languages, scripting or else. Many domain-specific languages do not accumulate to byte-code or executable code, but to various kinds of media substances: Graphic exports to PostScript, GIF, JPEG, etc., where Turing machine C Sound assembles to audio files, and a ray-tracing domain- specific language like POV compiles to illustrations files (Dutra & Patel, 2015). A computer language like SQL presents an interesting case: it can be deemed a domain-specific language because it is specific to a specific domain (in SQL's case, accessing and managing relational databases), and is often called from additional application, but SQL has more keywords and functions than many scripting languages, and is often thought of as a language in its own right, perhaps because of the prevalence of database operation in programming and the amount of mastery required to be an expert in the language.

Further blurring this line, many domain-specific languages have exposed APIs, and can be accessed from other programming languages without breaking the flow of execution or calling a separate process, and can thus operate as programming libraries.

Advantages

Some of advantages which align this evaluation by use of Turing machines include:

1) Concise, domain-specific notations, A DSL offers natural notations to more succinctly express the programmer’s intention.

2) Analysis and verification, the limited scope of a DSL enables a domain specific verification tool to analyze a DSL program and report domain- specific warnings and error messages.

3) Abstraction, A DSL can abstract from boilerplate code (low-level, repetitive code, e.g. the initialization sequence of a library) that has to be written by hand otherwise.

4) Platform independence, DSLs can abstract from a particular platform or implementation. Therefore, multiple implementations of a DSL can exist, e.g. an interpreter, a compiler that compiles the DSL to Java and a compiler that compiles to C.

5) Domain-specific tooling support, the limited application domain and higher level of abstraction of a DSL enable better program understanding. Consequently, there is an opportunity to offer better tooling as part of an Integrated Development Environment (IDE).

Challenges

Service providers are facing a two-dimensional challenge in deploying broadband access networks: the evolution of service demand and competition. e.g.

1) Managing non-vectored lines and legacy

2) Managing unbundled lines

3) Managing disorderly shutdown events

4) Managing binder groups

Conclusion

It has been clear that Turing machines are vectored in the new copper-based access technology breakthrough. It allows for significant data rate increases through crosstalk cancellation and allows service providers to deliver very- high-speed data services in a cost-effective manner. Vectored DSL merchandises are expected to soon become commercially available. Performance results from several constructors show that speeds of 100 Mb/s per line is achievable. Service providers will be faced with planning, operation, and management of vectored DSL considerations. However, the use of vectored DSL features and the leveraging of the DLM/DSM capabilities can ensure that essential line stability and desired QoE to customers are achieved

References

Badrinarayanan, S., Kalai, Y. T., Khurana, D., Sahai, A., & Winch’s, D. (2018). Non- Interactive Delegation for Low-Space Non-Deterministic Computation. Cryptology ePrint Archive, Report 2017/1250, 2017. To appear in STOC.

Dutra, R., Mehne, B., & Patel, J. (2015). BlindTM—a Turing machine system for secure function evaluation.

W. Henecka, S. K¨ogl, A. Reza Sadeghi, T. Schneider, and I. Wehrenberg. Tasty: Tool for automating secure two-party computations. In ACM Conference on Computer and Communications Security (ACM CCS'10, pages 451–462, 2010.