The universal blind quantum computation protocol (UBQC) enables an almost classical client to delegate a quantum computation to an untrusted quantum server (in the form of a garbled quantum circuit) while the security for the client is unconditional. In this contribution, we explore the possibility of extending the verifiable UBQC, to achieve further functionalities following the analogous research for classical circuits (Yao 1986). First, exploring the asymmetric nature of UBQC (the client preparing only single qubits, while the server runs the entire quantum computation), we present a “Yao”-type protocol for secure two-party quantum computation. Similar to the classical setting, our quantum Yao protocol is secure against a specious (quantum honest-but-curious) garbler, but in our case, against a (fully) malicious evaluator. Unlike the previous work on quantum two-party computation of Dupuis et al., 2010, we do not require any online-quantum communication between the garbler and the evaluator and, thus, no extra cryptographic primitive. This feature will allow us to construct a simple universal one-time compiler for any quantum computation using one-time memory, in a similar way to the classical work of Goldwasser et al., 2008, while more efficiently than the previous work of Broadbent et al., 2013.

Future information and communication networks will consist of both classical and quantum devices, some of which are expected to be dishonest. These devices will have various different functionalities, ranging from simple routers to servers executing quantum algorithms. Within the last few years, anticipating this development has led to the formation and growth of the field of delegated quantum computing [

The MBQC model of computation can be viewed as a set of classical instructions steering a quantum computation performed on a highly entangled quantum state. The classical outcomes of the single-system measurements that occur during the computation are in general randomly distributed bits with no significance for the final output of the computation. This enables one to use relatively basic obfuscation techniques in order to prevent an untrusted operator (that implements an MBQC computation) from obtaining access to the true flow of information. This key observation has led to an entirely new approach to quantum verification that exploits cryptographic techniques [

We will explore two extensions of the verifiable universal blind quantum computing (VUBQC) protocols, which are built based on measurement-based quantum computation, in order to achieve new functionalities to be implemented in the quantum network setting [

In

In

Deriving new quantum cryptographic protocols for functionalities beyond the secure key exchange [

Due to the impossibility results of [

Another related issue is that the server-client setting can also be exploited to achieve simpler (implementation-wise) multiparty blind quantum computation protocols, where multiple clients use a single server to jointly and securely perform a quantum computation [

Finally, an interesting future direction is to try to view secure two-party quantum computation (2PQC) as a quantum game. The link of classical SMPCand game theory has been analysed, for example, in connection with the issue of fairness and rational players [

We will assume that the reader is familiar with the measurement-based quantum computation (MBQC) model [

If one starts with a graph state where qubits are prepared in a rotated basis

The UBQC protocol can be uplifted to a verification protocol where the client can detect a cheating server. To do so, the client for certain vertices (called dummies) sends states from the set

We are given a base-graph

For each vertex

Corresponding to each edge

We replace every edge in the resulted graph with a new vertex connected to the two vertices originally joined by that edge. The new vertices added in this step are called added vertices. This is the dotted triple-graph

We can see (

For completeness, we give the basic verification protocol from [

The impossibility of achieving unconditionally secure two-party cryptographic protocols has led to the definition and use of simpler hardware or software primitives to form the basis for the desired functionalities. A one out of

The first paper that studied secure two-party quantum computation is [

(Taken from [

The trivial oracle is a communication oracle that transfers some quantum register from one party to another. Protocols that have only such oracles are called the bare model. Other oracles include calls to other cryptographic primitives. The quantum state in each step of the protocol is given by:

The security definitions are based on the ideal functionality of two-party quantum computation (2PQC) that takes a joint input

For other adversaries, the simulator is defined analogously.

Given input

In classical cryptography, a type of adversary commonly considered is the “honest-but-curious”. This adversary follows the protocol, but also keeps records of its actions and attempts to learn from those more than what it should. This type of weak adversary has been proven very useful in many protocols, since it typically constitutes the first step in constructing protocols secure against more powerful (even fully malicious) adversaries.

Since quantum states cannot be copied, one cannot have a direct analogue of honest-but-curious. Instead, we have the notion of specious adversaries [

Note that this (standard) definition of specious adversary allows for different interpretations that lead to stronger and weaker versions of the adversary. These subtleties are explained in

A 2PQC protocol needs to be (by definition) private. Moreover, it may have two extra properties, verification and fairness. Verification means that each party, when they receive their output, not only is sure that nothing leaked about its input, but also it can know whether the outcome it received is correct or corrupted. Fairness is the extra property that no party should be able to obtain its output and after that cause an abort (or a corruption) for the other party. Even in classical 2PC, it is impossible to have fairness against fully-malicious adversaries (without any extra assumption). We consider two-party protocols

The first extension of VUBQC that we will explore refers to its use in order to construct a 2PQC protocol similar to the classical Yao protocol of [

Our QYao protocol provides a one-time verifiable 2PQC similar to the classical setting as recently shown for the original Yao protocol in [

The major difference that the QYao protocol has in comparison with regular VUBQC [

The qubits composing the DT(G)(see

This extra encryption is needed in order to hide the future actual measurement of the input qubit (to be performed by the server) and ensure that no information about the position of the traps is leaked. Trap hiding also requires the client to return two extra qubits for the input insertion (see

Finally, after the server has received all of the qubits, he/she announces the secret keys

In the standard VUBQC protocol, the server returns all of the output qubits to the client. The client measures the final layer’s traps to check for any deviation and then obtains the output of the computation by decrypting the output computation qubits using their secret keys. In the 2PQC, part of the output (of known base-locations) should remain in the hands of the server. This, however, would not allow the client to check for the related traps (that could have effects on other output qubits). Similar to the input injection, the solution is obtained via an extra layer of encryption by the server followed by a delayed key releasing. The server will encrypt using two classical bits

We combine Protocols 3 and 4 with the core VUBQC, Protocol 1, to obtain a secure two-party protocol to compute unitaries given as Protocol 5. An illustration of a simple example is given in

The server sends to the client the states

The client prepares all of the states of the DT(G) as in Protocol 1 (see [

The client chooses at random

The client mixes the computation qubit of the server’s input, with a dummy and a trap qubit to return the three qubits of server’s input base-locations.

The server, after receiving the qubits, returns to the client the secret bits

The client computes

The server sends to the client the states

The client keeps the qubits that correspond to traps and dummies in the final layer of server’s output, while returns the computation qubits of server’s output.

The server returns to the client

The client checks the traps and if correct returns to the server the final layer paddings for their output locations

The server undoes the final layer paddings and obtains the output.

If the client and server follow Protocol 5, after Step 1, where the server injected its input, we are in exactly the same situation as in Protocol 1, with (overall) input

During Step 2, the client and server run exactly Protocol 1, and the correctness follows from the correctness of that protocol; the proof is given in [

The client and server know the unitary operator

The client receives the subset

The server receives the subset

Client sends all qubits of the DT(G) (choosing the random parameters

Server and client follow the verification protocol 1 until the step that the output is returned.

Client and server interact according to Protocol 4 so that the server extracts their own output.

During Step 3, the client keeps the registers of its output, while returning the registers of the server’s output. The protocol finishes with the server returning its keys

Since the protocol we give is generic for any quantum computation, the complexity of the 2PQC protocol with respect to the input size depends on the specific computation/algorithm used, and it is against this that it should be compared. At this point, we should stress that the number of qubits required for the 2PQC protocol is exactly the same as those to perform the same computation using VUBQC where all input and output are of the client. From [

Due to the simple composition of input injection and output extraction, the verification property of our QYao is directly inherited from the VUBQC. We prove this first, before presenting and proving the main privacy property of the QYao protocol in the next section (which exploits the verifiability).

We should note that the server can always choose any input from its side, and the security of the protocol is defined with respect to this “deviated” input. Moreover, since the deviation

In order to prove the verifiability for the client, we assume that the client is honest, while the server is malicious.

During Step 1 of Protocol 5, the server sends his/her input and also gives the keys of the one-time padding encryption

During Step 2, the protocol proceeds exactly as the VUBQC, Protocol 1, with the only difference that the qubits with the base-location of the server’s output have an extra encryption with keys known to the server. This means that the client delays the measurement of the traps in those base-locations, until the next step, where it receives from the server these keys. Note, however, that the client can already check all of the past traps and the ones corresponding to base-location of the clients’ output.

In Step 3, the server returns the keys

It follows that this protocol has the same verification properties as Protocol 1, with the modified input and (server’s part) of the output given by Equation (

It is worth mentioning that this verification property essentially restricts the server to behave similarly as a specious adversary, with the extra ability to abort the protocol.

Recall that we defined a protocol to be secure if no possible adversary in any step of the protocol can distinguish whether it interacts with the real protocol or with a simulator that has access only to the ideal functionality (see Definition 4).

To prove the theorem, we need to introduce simulators for each step of the protocol and each possible adversary. Below, we define those simulators and prove that they are as close to the real protocol as requested from Theorem 3. Since in our setting, the two parties have different roles and maliciousness, we consider the simulators for each party separately.

The client is

Following the proof of the “rushing lemma” of [

This proof follows closely the proof of the “rushing lemma” of [

The state

By the triangular inequality, we get

Before introducing the simulators, we give some intuitive arguments. The client, during the input-injection step, receives a fully-one-time padded quantum state, while in later steps (up until the last), it has no legitimate quantum state (all of the quantum states are in the server’s side). Therefore, using the above lemma, we can already see that the client has no information about the actual quantum state during any step before the last. This is illustrated by the fact that the simulators for these steps can run the honest protocol with a random (but fixed) input, and the client’s view is the same (they cannot distinguish a run with the correct or different input in any step before the last). The simulator for the final step (after receiving the quantum states from the server) is more subtle, as it necessarily involves a call to the ideal functionality.

Simulator upon receiving the server’s encoded input: There is a full one-time pad on the server’s input; thus, a simulator can use a random fixed state

Simulator after returning the server’s input and before receiving output: The simulator runs the honest protocol using instead of

The simulator runs the protocol with fixed but random input

The simulator obtains the fixed state

The simulated view is then defined to be:

By

We also assume that the classical measurement outcomes

The final layer (unmeasured) qubits are separated into: (i) output qubits (those of the server and the client; and it includes the purification of their inputs), (ii) dummy qubits collectively denoted

The Hilbert spaces containing the output qubits (and the related purification of honest run) are denoted

For brevity, we denote

With the above notations, the honest run of the protocol at this step, with some input

We define:

It is worth pointing out that

The simulator obtains from the client the choice of secret keys

The simulator sets

The simulator, using the previous steps, constructs the state

The simulator uses the state

The simulator calls the ideal functionality and receives the state

The simulator uses the keys and the state received from the ideal functionality and constructs

The simulator obtains the operator

The simulated view is then:

It is clear that in all of this construction,

We start from Equation (

Now, since

☐

Our QYao protocol is secure against a fully-malicious server that can deviate in any possible way and can also cause an abort. We will use the fact that the QYao protocol is

We can see that, before the client sends the secret parameters, the server is totally blind, i.e., the server’s reduced state at all times is the totally mixed state (for all qubits in the DT(G), including their own input qubits, after they are injected). This is highlighted by the fact that one can run the full protocol (before releasing the keys), without choosing the (client’s) input (see simulator below). After receiving the keys from the client, to simulate the server’s view, we need a call to the ideal functionality and, at this point, to use Equation (

Simulator before receiving keys: The simulator, instead of sending qubits in one of these states

Simulator after receiving keys: The simulator is constructed using the following steps:

The simulator prepares multiple Bell states

The simulator for each qubit chooses randomly an angle

The simulator obtains from the server’s (malicious) strategy the parameter

With probability

The simulator calls the ideal functionality and obtains the state

The simulator encrypts the outcome using

The simulator returns the keys

The last step of the protocol is that the server decrypts its output. The decryption is denoted as

From Equation (

We have now proven that the simulated view is

Following the classical approach of [

Recall that the interaction in our QYao is required for two reasons. First, from the server’s perspective, this is done to obtain the measurement angles

Removing the interaction: An obvious solution for the first issue raised is to have the client compute

For each influence-past

Similarly we define the extended-influence-past (EIP) of qubit

Ensuring verification: The interaction is also important from the clients’ perspective, in order to verify that the server did not deviate. Again, one could naively suggest that the server can return all of the measurement outcomes at the end. However, this suffers from a potential attack (not present in normal VUBQC). The underlying reason is that there is nothing to force the server to commit that the

The client provides for each qubit the angle

For each qubit

According to this protocol, the flag that the server obtains when opening the OTM at qubit

If for all traps

Otherwise, we return a random string

Client and server interact according to Protocol 3 to obtain the server’s input locations. Client also sends the qubits of DT(G) after choosing secret parameters (

The client, for each qubit and each extended influence past, computes

Server performs the measurements according to the first layer of angles received

Server and client interact according to Protocol 4 so that the server obtains their output. The only difference is that the client, before returning the keys, in order to accept checks the flags (instead of checking the trap outcomes of measured qubits) and the final layer traps.

This protocol requires exactly the same number of qubits as Protocol 5. The only extra “cost” is that we require one OTM per qubit. The size of the labels of the OTM is one-out-of-

This proof consists of three stages. First, similarly to the proof of theorem 2, we show that the verifiability for the client of the non-interactive QYao reduces to the verifiability of the same VUBQC protocol with modifications for the server’s input and output. The second stage is to observe that the optimal strategy for an adversarial server is to return the flags from the opened OTMs. This makes the verifiability property for this protocol identical to an interactive protocol with the only modification that the server can return different values for the measurement outcome

Stage 1: Following the proof of Theorem 2, we can see that the non-interactive QYao Protocol 7 is

Stage 2: If the server attempts to guess a flag (given the extra knowledge of one bit-string

It follows that the adversary (trying to maximising its cheating chances) should return the flags found in the OTMs. This is equivalent to an interactive VUBQC protocol, for which= (i) the server for each qubit

Stage 3: We should now show the

For the proof of verifiability, as in [

In our case, there is the difference that for each measured qubit

We need simulators for the client only during input injection and output extraction (since the client does not participate in the evaluation phase, in the non-interactive protocol). During these steps, the simulators are identical to those in Protocol 5.

The server’s simulators until before the output extraction can be identical with the ones of Protocol 5, where the interaction is replaced with the preparation of OTMs. It is important to note that all OTMs can be constructed with no information about the client’s input and thus from the simulator. Finally, the simulator for the final step of Protocol 5 needs to only use the property that the protocol is

We gave a protocol for 2PQC, secure against specious adversaries. Our protocol differs significantly from [

Furthermore, due to a subtle difference in the definition of specious adversaries, our protocol requires no extra primitives (see the details in

Finally, we obtained a one-time compiler for any quantum computation using one-time memories. This was done following the classical work of Goldwasser et al. [

We would like to thank Frédéric Dupuis for discussions on the definition of specious adversaries. Funding from EPSRCGrants EP/N003829/1 and EP/M013243/1 is acknowledged.

Both authors contributed to developing the theory and writing the paper.

The authors declare no conflict of interest.

The following abbreviations are used in this manuscript:

An MBQC pattern is fully characterised by the graph (representing the entangled state), default measurement angles

For the brickwork state, or any subset of the square lattice state, the flow

We present here diagrams taken from [

The definition of specious, as given by Equation (

The first important point is that we observe that a specious adversary, under certain conditions, could be weaker than an honest-but-curious classical adversary. A specious adversary is allowed to do actions/operations that for any (allowed) input can be “undone” by actions on his/her side if there is an audit.

Now, we consider a (trivial) example that specious is weaker than classical honest-but-curious. Assume that as the first step of a protocol, a party (that is specious adversary)

There is no map that

However, imagine that we are actually considering a classical protocol, which means that the input is in computational basis, i.e., either

The second important subtlety of the specious definition is related to the secret (random) parameters that the adversary can choose. Specious adversaries should be able to recover the global state

However, we can imagine an adversary

We will define the strong specious adversary to be the adversary that is required to have CP maps

We will again give a simple example to make the distinction of these two flavours of specious adversaries. Imagine a protocol that a (strong or weak) specious adversary

It is not difficult to see that a protocol that is secure against the standard (weak) specious adversary can be made secure against the strong specious adversary by modifying the protocol to request that in every step a new random (secret) parameter appears, a commitment to its value is made. This means that requesting an adversary to be weak specious is practically equivalent to a strong specious adversary where commitments are allowed.

Here, it is worth mentioning that in [

We will now give two simple examples (one for Protocol 5 and one for Protocol 7) to illustrate how the generic protocols given work practically.

We consider a simple example for Protocol 5 where each of the clients/servers has a single qubit input/output, and the unitary/computation to be implemented is a CNOT gate. The MBQC pattern for this gate is given in

MBQC patterns for different gates: (

Dotted base-graph for a CNOTgate.

Dotted base-graph for a CNOT gate along with isolated traps/tags. The input/output of the client/server is coloured blue.

Finally, we note that in UBQC, the measurement angle that the client instructs the server to measure is given:

The protocol starts with the server’s input injection, where the server gives his/her input (bottom left blue qubit in

The client instructs the server to measure the qubits at angles

The client, from his/her view, taking into account the pre-rotations

Finally is the server’s output extraction part (see

In this example, we are not concerned with the input/output constructions, as these are similar to Protocol 5. Instead, we give the simplest example of a base-graph to illustrate what influence-past and extended influence-past means and how the flags and the OTMs are constructed.

We start with the simplest base-graph of two qubits given in

(

The view of the client (that knows the trap-colouring) is given in

(

Now, influence-past is defined in terms of which qubit results in a

The extended influence-past includes all of the qubits that for some trap-colouring could be at the influence-past, and it is a superset of the influence-past. In other words, all of the qubits that belong to the same base-location as the true influence-past are always included. We consider the last layer qubits

Now, we describe the OTMs. First, the cells of each OTM are labelled according to different outcomes of qubits in the extended influence-past. In other words, for the OTM for Qubit 13, we will have one cell for each string of measurement outcomes of the qubits

Finally, we stress again that in the above table, the influence-past and non-trivial flag dependence is not known to the server, while the extended influence-past is.

We prove here that the partial trace over one system commutes with any operation to the non-traced-out system. We express a generic density matrix

Similarly, a general operator

It is easy to see that:

Dotted triple graph. Circles: primary vertices with the base-location of the vertex of the base-graph; squares: added vertices with the base-location of edges of the base-graph. (

The server gives its input (blue), and the client chooses (randomly) where in the input base-location to place the input. The random choice is highlighted. The trap-colouring is filled correspondingly, after the random choice is made.