Pseudo-Secret Random Qubit Generator (PSQRG): Difference between revisions
No edit summary |
|||
(28 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
The [https://arxiv.org/abs/1802.08759 example protocol] enables fully-classical parties to generate secret single qubit states using only public classical channels and a single quantum Server. This functionality could be used to replace a quantum channel completely such that a classical Client can perform various quantum applications over classical network connected to a quantum Server. An application of this functionality could be to carry out [[Secure Client- Server Delegated Computation|Delegated Quantum Computation]] by just classical online communication (classical communication throughout the protocol) and no quantum communication. It allows a fully classical Client to instructs Server to generate random single qubit states such that Client has complete knowledge of the state of qubit prepared but Server does not. It can be used for [[Prepare-and-Send Universal Blind Quantum Computation|UBQC]], [[Prepare-and-Send Verifiable Universal Blind Quantum Computation|VUBQC]] and for other protocols like Quantum Money, Quantum Digital Signatures etc.. which need user to share his/her private quantum key over a quantum channel. | |||
==Use Case== | ==Use Case== | ||
* | *Quantum Task | ||
*No classical Analogue | |||
*Replaces quantum channels by classical channels for quantum cloud computing | |||
*Generating random qubits for protocols like quantum-key-distribution, quantum money, quantum coin-flipping, quantum signatures, two-party quantum computation, multiparty quantum computation etc. | *Generating random qubits for protocols like quantum-key-distribution, quantum money, quantum coin-flipping, quantum signatures, two-party quantum computation, multiparty quantum computation etc. | ||
'''Tags:''' [[Category: Two Party Protocols]] [[:Category: Two Party Protocols|Two Party]], [[Category: Universal Task]][[:Category: Universal Task|Universal Task]], [[Category: Quantum Functionality]] [[:Category: Quantum Functionality|Quantum Functionality]], Classical Online Communication, [[Supplementary Information#Protocols|Superposition]], [[Supplementary Information#Collision Resistant Functions|Collision Resistant Functions]], [[Supplementary Information#Learning With Errors|Learning With Errors]] | |||
==Assumption== | |||
*This protocol assumes an honest Client and proves security only for an adversarial Server. | |||
*This protocol takes the assumption of a Quantum Honest But Curious (QHBC) adversary setting i.e. the protocol is secure against an honest Server who just wants to know Client’s hidden data but not modify it without Client’s consent. | |||
== Outline == | == Outline == | ||
The general idea is that a classical Client gives instructions to a quantum Server to perform certain actions (quantum computation). Those actions lead to the Server having as output a single qubit, which is randomly chosen from within a set of chosen (by the Client) states. On the other hand, Client is supposed to know the classical description of Server's output qubit. To achieve this task, the instructions/quantum computation the Client uses are based on a family of trapdoor, two regular, one-way functions with certain extra properties (see Properties and Definitions). Trapdoor one-way functions are hard to invert (e.g. for the Server) unless someone (the Client in this case) has some extra “trapdoor” information. Two-regular functions have two pre-images for every value in the range of the function. This extra information helps the Client classically reproduce the quantum computation to recover the classical description of the single qubit state, while it is still hard to classically reproduce for the Server, the same information as Client. Simple modifications to the protocol could achieve other similar sets of states.<br/><br/> | The general idea is that a classical Client gives instructions to a quantum Server to perform certain actions (quantum computation). Those actions lead to the Server having as output a single qubit, which is randomly chosen from within a set of chosen (by the Client) states. On the other hand, Client is supposed to know the classical description of Server's output qubit. To achieve this task, the instructions/quantum computation the Client uses are based on a family of trapdoor, two regular, one-way functions with certain extra properties (see [[Pseudo-Secret Random Qubit Generator (PSQRG)#Properties|Properties]] and [[Pseudo-Secret Random Qubit Generator (PSQRG)#Definitions|Definitions]]). Trapdoor one-way functions are hard to invert (e.g. for the Server) unless someone (the Client in this case) has some extra “trapdoor” information. Two-regular functions have two pre-images for every value in the range of the function. This extra information helps the Client classically reproduce the quantum computation to recover the classical description of the single qubit state, while it is still hard to classically reproduce for the Server, the same information as Client. Simple modifications to the protocol could achieve other similar sets of states.<br/><br/> | ||
The protocol can be divided into two stages, Pre-images Superposition, where Client instructs the Server to generate superposition using the function with above properties and, Squeezing, where the Server is instructed by the Client to measure his output qubits and deliver outcomes, which she (Client) would use to classically compute the value of r. | The protocol can be divided into two stages, Pre-images Superposition, where Client instructs the Server to generate superposition using the function with above properties and, Squeezing, where the Server is instructed by the Client to measure his output qubits and deliver outcomes, which she (Client) would use to classically compute the value of r. | ||
*'''Preparation.''' Client randomly selects a function with required properties, which is public (Server knows), but the trapdoor information needed to invert the function is known only to the Client. | *'''Preparation.''' Client randomly selects a function with required properties, which is public (Server knows), but the trapdoor information needed to invert the function is known only to the Client. | ||
*'''Preimages Superposition.''' Server prepares two quantum registers (system comprising multiple qubits), first being control (containing inputs) and second being target (containing output of the function). Client instructs Server to create a superposition of input states by applying [[ | *'''Preimages Superposition.''' Server prepares two quantum registers (system comprising multiple qubits), first being control (containing inputs) and second being target (containing output of the function). Client instructs Server to create a [[Glossary#Superposition|superposition]] of input states by applying [[Glossary#Unitary Operations|Hadamard gate]] (quantum fourier transform) on control register. She then instructs Server to apply a [[Glossary#Unitary Operations|unitary gate]] (all quantum gates are represented by unitary matrices) which computes output of the function in the target register, taking input from the control register, thus yielding an entangled state from the Server's superposition state. Server is required to measure the target register in the computational basis (along Z axis) and get an outcome. This action would reduce the control register into a superposition of two pre-images corresponding to the measurement outcome of the target register. He conveys this outcome to the Client who computes, classically, the two pre-images using her trapdoor. This pair of pre-image would have some isolated similar qubits (without superposition) and a superposition of dissimilar qubits. The dissimilar qubits can be written as a superposition of isolated 0s and isolated 1s (a GHZ state), with [[Glossary#Unitary Operations|X (NOT) gates]] applied to qubits depending on the state of qubit in both the pre-images. If the last qubit belongs to the set of similar qubits, then Client aborts and this Stage is repeated. | ||
*'''Squeezing.''' Client instructs Server to measure all the qubits of the control register in some basis chosen randomly by the Client, except the last one, and return to her the outcomes. The last unmeasured state contains the randomly prepared qubit hidden from the Server. Client can then compute the value of r by an equation (see Pseudo Code). This equation depends only on Client’s measurement basis angles, Server’s measurement outcome and the location of random X’s (unknown to the Server). Thus, the Client knows the state of her secret qubit prepared by the Server. | *'''Squeezing.''' Client instructs Server to measure all the qubits of the control register in some basis chosen randomly by the Client, except the last one, and return to her the outcomes. The last unmeasured state contains the randomly prepared qubit hidden from the Server. Client can then compute the value of r by an equation (see [[Pseudo-Secret Random Qubit Generator (PSQRG)#Pseudo Code|Pseudo Code]]). This equation depends only on Client’s measurement basis angles, Server’s measurement outcome and the location of random X’s (unknown to the Server). Thus, the Client knows the state of her secret qubit prepared by the Server. | ||
==Requirements== | |||
*'''Network Stage:''' [[:Category:Quantum Memory Network Stage|Quantum Memory]] [[Category:Quantum Memory Network Stage]] | |||
*'''Required Network Parameters:''' | |||
**'''<math>\epsilon_j</math>''', which measures the error due to noisy operations. | |||
**Number of communication rounds | |||
**Circuit depth | |||
**Number of physical qubits used | |||
*Client needs a classical computer | |||
*Quantum offline channel | |||
*Classical online channel | |||
*Server should be able to generate [[Glossary#Superposition|superposition]], apply single qubit gates, store entangled states, perform measurement. | |||
*Notations | ==Knowledge Graph== | ||
{{graph}} | |||
== Properties == | |||
*<math>f_k</math>, the function with required properties as given below in point 4. | |||
*n, number of qubits in the control register. | |||
*The function used for the protocol is required to satisfy the following properties: one-way, trapdoor, two-regular, collision resistance, quantum-safe (See Definitions). | |||
*This protocol is secure under learning with errors assumption i.e. it relies on assumption over a quantum Server to be unable solve a computationally hard problem. | |||
*The protocol assumes that all quantum operators are described by polynomially-sized circuits. | |||
*The randomness of the output qubit is due to the (fundamental) randomness of quantum measurements that are part of the instructions that the Client gives. | |||
*The Server cannot guess the state any better than if he had just received that state directly from the Client (up to negligible probability). | |||
*''Correctness'' If both the Client and the Server follow the protocol, the protocol aborts when {missing equation}, while otherwise the Server ends up with the output (single) qubit being in the state ), where <math>\theta</math> is given by [[equation|equation]] (see Pseudo Code). | |||
* The single qubit state generated by the protocol remains private against a QHBC Server. | |||
==Notations== | |||
**<math>f_k</math>, function for target register | **<math>f_k</math>, function for target register | ||
**<math>t_k</math>, trapdoor for function <math>f_k</math> | **<math>t_k</math>, trapdoor for function <math>f_k</math> | ||
Line 28: | Line 56: | ||
**<math>b_i</math>, Server’s measurement outcome for qubit i in the control register | **<math>b_i</math>, Server’s measurement outcome for qubit i in the control register | ||
**<math>\theta</math>, classical description of the hidden input state | **<math>\theta</math>, classical description of the hidden input state | ||
==Protocol Description== | |||
==='''Stage1''' Preimages superposition=== | |||
'''Requirements:''' </br> | |||
Public: A family <math>\mathcal{F}=\{f_k : \{0,1\}^n \rightarrow \{0,1\}^m \}</math> of trapdoor one-way functions that are quantum-safe, two-regular and collision resistant (or second preimage resistant) (See article for Function Construction)</br> | |||
'''Input:''' Client uniformly samples a set of random three-bits strings: | |||
<math>\alpha=(\alpha_1,\cdots,\alpha_{n-1})</math> where <math>\alpha_i\leftarrow\{0,1\}^3</math>, and runs the algorithm <math>(k,t_k) \leftarrow \text{Gen}_{\mathcal{F}}(1^n)</math>. The <math>\alpha</math> and <math>k</math> are public inputs (known to both parties), while <math>t_k</math> is the ''private'' input of the Client. | |||
* Client: instructs Server to prepare one register at <math>\otimes^n H |0\rangle</math> and second register initiated at <math>|0\rangle^{m}</math> | |||
* Client: returns <math>k</math> to Server and the Server applies <math>U_{f_k}</math> using the first register as control and the second as target | |||
* Server: measures the second register in the computational basis, obtains the outcome <math>y</math> and returns this result <math>y</math> to the Client. Here, an honest Server would have a state <math>{(|x\rangle+|x'\rangle) \otimes |y\rangle}</math> with <math>f_k(x)=f_k(x')=y</math> and <math>y\in \Im f_k</math>. | |||
* Client can rewrite the superposition in the control register for herself as, | |||
<math>(|x\rangle+|x'\rangle)=(|x_1\cdots x_n\rangle+|x'_1\cdots x'_n\rangle)</math> | |||
<math>=\big(\otimes_{i\in \bar{G}}|x_{i}\rangle\big)\otimes\big(\otimes_{j\in G}|x_{j}\rangle+\otimes_{j\in G}|x_{j}\oplus 1\rangle\big)</math> | |||
<math>\quad\quad\quad\quad\quad\quad=\big(\otimes_{i\in \bar{G}}|x_{i}\rangle\big)\otimes\Big(\prod_{j\in G}X^{x_{j}}\Big)\big(|0\cdots 0\rangle_{G}+|1\cdots 1\rangle_{G}\big)</math>,</br> | |||
where <math>\bar{G}</math> is the set of bits positions where <math>x,x'</math> are identical, <math>G</math> is the set of bits positions where the pre-images differ, while suitably changing the order of writing the qubits. | |||
==='''Stage2''' Squeezing=== | |||
*'''Output''': If the protocol is run honestly, when there is no abort, the state that Server has is <math>+_{\theta}</math>, where the Client (only) knows the classical description. | |||
#Client: instructs the Server to measure all the qubits (except the last one) of the first register in the <math>\left\{|0\rangle\pm e^{\alpha_i\pi/4}|1\rangle\right\}</math> basis. Server obtains the outcomes <math>b=(b_1,\cdots,b_{n-1})</math> and returns the result <math>b</math> to the Client. | |||
#Client: using the trapdoor <math>t_k</math> computes <math>x,x'</math>. Then check if the <math>n^{\text{th}}</math> bit of <math>x</math> and <math>x'</math> (corresponding to the y received in stage 1) are the same or different. If they are the same, returns abort, otherwise, obtains the classical description of the Server’s state. | |||
==Definitions (informal)== | ==Definitions (informal)== | ||
Line 36: | Line 86: | ||
*''Two-regular'' A deterministic function <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is two-regular if <math>\forall y \epsilon Im(f)</math>, we have <math>|f^{-1}(y)| = 2</math> | *''Two-regular'' A deterministic function <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is two-regular if <math>\forall y \epsilon Im(f)</math>, we have <math>|f^{-1}(y)| = 2</math> | ||
*''Trapdoor Function'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is a trapdoor function if there exists a QPT algorithm Gen which on input <math>1^n</math> outputs <math>(k,t_k)</math>, where k represents the index of a function, <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math>, where <math>f_k</math> is a one-way function, then there exists a QPT algorithm Inv, which on inputs <math>t_k</math> (which is called the trapdoor information) which was output by Gen(<math>1^n</math>), and <math>y = f_k(x)</math> can invert y (by returning all pre-images of y with non-negligible probability over the choice of <math>(k,t_k)</math> and uniform choice of x. | *''Trapdoor Function'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is a trapdoor function if there exists a QPT algorithm Gen which on input <math>1^n</math> outputs <math>(k,t_k)</math>, where k represents the index of a function, <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math>, where <math>f_k</math> is a one-way function, then there exists a QPT algorithm Inv, which on inputs <math>t_k</math> (which is called the trapdoor information) which was output by Gen(<math>1^n</math>), and <math>y = f_k(x)</math> can invert y (by returning all pre-images of y with non-negligible probability over the choice of <math>(k,t_k)</math> and uniform choice of x. | ||
==Further Information== | |||
The above protocol coined the functionality of producing pseudo random qubits via a completely classical client, blind to the server that generated it. A verification of this protocol is still an open question. | |||
<div style='text-align: right;'>''*contributed by Shraddha Singh''</div> | |||
*'' | |||
Latest revision as of 15:44, 16 October 2019
The example protocol enables fully-classical parties to generate secret single qubit states using only public classical channels and a single quantum Server. This functionality could be used to replace a quantum channel completely such that a classical Client can perform various quantum applications over classical network connected to a quantum Server. An application of this functionality could be to carry out Delegated Quantum Computation by just classical online communication (classical communication throughout the protocol) and no quantum communication. It allows a fully classical Client to instructs Server to generate random single qubit states such that Client has complete knowledge of the state of qubit prepared but Server does not. It can be used for UBQC, VUBQC and for other protocols like Quantum Money, Quantum Digital Signatures etc.. which need user to share his/her private quantum key over a quantum channel.
Use Case[edit]
- Quantum Task
- No classical Analogue
- Replaces quantum channels by classical channels for quantum cloud computing
- Generating random qubits for protocols like quantum-key-distribution, quantum money, quantum coin-flipping, quantum signatures, two-party quantum computation, multiparty quantum computation etc.
Tags: Two Party,Universal Task, Quantum Functionality, Classical Online Communication, Superposition, Collision Resistant Functions, Learning With Errors
Assumption[edit]
- This protocol assumes an honest Client and proves security only for an adversarial Server.
- This protocol takes the assumption of a Quantum Honest But Curious (QHBC) adversary setting i.e. the protocol is secure against an honest Server who just wants to know Client’s hidden data but not modify it without Client’s consent.
Outline[edit]
The general idea is that a classical Client gives instructions to a quantum Server to perform certain actions (quantum computation). Those actions lead to the Server having as output a single qubit, which is randomly chosen from within a set of chosen (by the Client) states. On the other hand, Client is supposed to know the classical description of Server's output qubit. To achieve this task, the instructions/quantum computation the Client uses are based on a family of trapdoor, two regular, one-way functions with certain extra properties (see Properties and Definitions). Trapdoor one-way functions are hard to invert (e.g. for the Server) unless someone (the Client in this case) has some extra “trapdoor” information. Two-regular functions have two pre-images for every value in the range of the function. This extra information helps the Client classically reproduce the quantum computation to recover the classical description of the single qubit state, while it is still hard to classically reproduce for the Server, the same information as Client. Simple modifications to the protocol could achieve other similar sets of states.
The protocol can be divided into two stages, Pre-images Superposition, where Client instructs the Server to generate superposition using the function with above properties and, Squeezing, where the Server is instructed by the Client to measure his output qubits and deliver outcomes, which she (Client) would use to classically compute the value of r.
- Preparation. Client randomly selects a function with required properties, which is public (Server knows), but the trapdoor information needed to invert the function is known only to the Client.
- Preimages Superposition. Server prepares two quantum registers (system comprising multiple qubits), first being control (containing inputs) and second being target (containing output of the function). Client instructs Server to create a superposition of input states by applying Hadamard gate (quantum fourier transform) on control register. She then instructs Server to apply a unitary gate (all quantum gates are represented by unitary matrices) which computes output of the function in the target register, taking input from the control register, thus yielding an entangled state from the Server's superposition state. Server is required to measure the target register in the computational basis (along Z axis) and get an outcome. This action would reduce the control register into a superposition of two pre-images corresponding to the measurement outcome of the target register. He conveys this outcome to the Client who computes, classically, the two pre-images using her trapdoor. This pair of pre-image would have some isolated similar qubits (without superposition) and a superposition of dissimilar qubits. The dissimilar qubits can be written as a superposition of isolated 0s and isolated 1s (a GHZ state), with X (NOT) gates applied to qubits depending on the state of qubit in both the pre-images. If the last qubit belongs to the set of similar qubits, then Client aborts and this Stage is repeated.
- Squeezing. Client instructs Server to measure all the qubits of the control register in some basis chosen randomly by the Client, except the last one, and return to her the outcomes. The last unmeasured state contains the randomly prepared qubit hidden from the Server. Client can then compute the value of r by an equation (see Pseudo Code). This equation depends only on Client’s measurement basis angles, Server’s measurement outcome and the location of random X’s (unknown to the Server). Thus, the Client knows the state of her secret qubit prepared by the Server.
Requirements[edit]
- Network Stage: Quantum Memory
- Required Network Parameters:
- , which measures the error due to noisy operations.
- Number of communication rounds
- Circuit depth
- Number of physical qubits used
- Client needs a classical computer
- Quantum offline channel
- Classical online channel
- Server should be able to generate superposition, apply single qubit gates, store entangled states, perform measurement.
Knowledge Graph[edit]
Properties[edit]
- , the function with required properties as given below in point 4.
- n, number of qubits in the control register.
- The function used for the protocol is required to satisfy the following properties: one-way, trapdoor, two-regular, collision resistance, quantum-safe (See Definitions).
- This protocol is secure under learning with errors assumption i.e. it relies on assumption over a quantum Server to be unable solve a computationally hard problem.
- The protocol assumes that all quantum operators are described by polynomially-sized circuits.
- The randomness of the output qubit is due to the (fundamental) randomness of quantum measurements that are part of the instructions that the Client gives.
- The Server cannot guess the state any better than if he had just received that state directly from the Client (up to negligible probability).
- Correctness If both the Client and the Server follow the protocol, the protocol aborts when {missing equation}, while otherwise the Server ends up with the output (single) qubit being in the state ), where is given by equation (see Pseudo Code).
- The single qubit state generated by the protocol remains private against a QHBC Server.
Notations[edit]
- , function for target register
- , trapdoor for function
- , Unitary operated on the target register taking first register as control, used to compute output of the function in the target register
- y, measurement outcome of the target register
- , pre-image pair for a given measurement outcome y
- value of qubit i for pre-image x
- value of qubit i for pre-image x’
- , Client’s measurement angles for qubit i in the control register
- , Server’s measurement outcome for qubit i in the control register
- , classical description of the hidden input state
Protocol Description[edit]
Stage1 Preimages superposition[edit]
Requirements:
Public: A family of trapdoor one-way functions that are quantum-safe, two-regular and collision resistant (or second preimage resistant) (See article for Function Construction)
Input: Client uniformly samples a set of random three-bits strings:
where , and runs the algorithm . The and are public inputs (known to both parties), while is the private input of the Client.
- Client: instructs Server to prepare one register at and second register initiated at
- Client: returns to Server and the Server applies using the first register as control and the second as target
- Server: measures the second register in the computational basis, obtains the outcome and returns this result to the Client. Here, an honest Server would have a state with and .
- Client can rewrite the superposition in the control register for herself as,
,
where is the set of bits positions where are identical, is the set of bits positions where the pre-images differ, while suitably changing the order of writing the qubits.
Stage2 Squeezing[edit]
- Output: If the protocol is run honestly, when there is no abort, the state that Server has is , where the Client (only) knows the classical description.
- Client: instructs the Server to measure all the qubits (except the last one) of the first register in the basis. Server obtains the outcomes and returns the result to the Client.
- Client: using the trapdoor computes . Then check if the bit of and (corresponding to the y received in stage 1) are the same or different. If they are the same, returns abort, otherwise, obtains the classical description of the Server’s state.
Definitions (informal)[edit]
- Quantum-Safe A protocol/function is quantum-safe (also known as post-quantum secure), if all its properties remain valid when the adversaries are quantum polynomial-time (QPT).
- One-Way A family of functions is one-way if there exists a QPT algorithm that can compute for any k, any input x ∈ D, and any QPT algorithm can invert with at most negligible probability over the choice of k.
- Second pre-image Resistant A family of functions is second pre-image resistant if there exists a QPT algorithm that can compute for any index function k, any input x ∈ D, and given an input x, it can find a different input such that with at most negligible probability over the choice of k.
- Collision Resistant A family of functions is collision resistant if there exists a QPT algorithm that can compute for any index function k, any input , any QPT algorithm can find two inputs such that with at most negligible probability over the choice of k.
- Two-regular A deterministic function is two-regular if , we have
- Trapdoor Function A family of functions is a trapdoor function if there exists a QPT algorithm Gen which on input outputs , where k represents the index of a function, , where is a one-way function, then there exists a QPT algorithm Inv, which on inputs (which is called the trapdoor information) which was output by Gen(), and can invert y (by returning all pre-images of y with non-negligible probability over the choice of and uniform choice of x.
Further Information[edit]
The above protocol coined the functionality of producing pseudo random qubits via a completely classical client, blind to the server that generated it. A verification of this protocol is still an open question.