Editing Pseudo-Secret Random Qubit Generator (PSQRG)

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
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 [[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 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 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.
Please note that all contributions to Quantum Protocol Zoo may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Quantum Protocol Zoo:Copyrights for details). Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel Editing help (opens in new window)

Template used on this page: