Write, autoreview, editor, reviewer
3,129
edits
Pseudo-Secret Random Qubit Generator (PSQRG): Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 6: | Line 6: | ||
'''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, [[Superposition]], [[Supplementary Information#Collision Resistant Functions|Collision Resistant Functions]], [[Supplementary Information#Learning With Errors|Learning With Errors]] | '''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, [[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 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/> | ||
| Line 13: | Line 15: | ||
*'''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|Hadamard gate]] (quantum fourier transform) on control register. She then instructs Server to apply a [[unitary gate|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)|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. | *'''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|Hadamard gate]] (quantum fourier transform) on control register. She then instructs Server to apply a [[unitary gate|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)|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 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. | ||
==Notations== | ==Notations== | ||
**<math>f_k</math>, function for target register | **<math>f_k</math>, function for target register | ||
| Line 24: | Line 27: | ||
**<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 | ||
== 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. | |||
==Pseudocode== | ==Pseudocode== | ||