Write, autoreview, editor, reviewer
3,125
edits
Pseudo-Secret Random Qubit Generator (PSQRG): Difference between revisions
Pseudo-Secret Random Qubit Generator (PSQRG) (edit)
Revision as of 07:17, 11 July 2019
, 11 July 2019→Outline
| Line 12: | Line 12: | ||
*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. | *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. | ||