Write, autoreview, editor, reviewer
3,129
edits
Line 1: | Line 1: | ||
==Functionality Description== | ==Functionality Description== | ||
Secret Random Qubit Generator (SQRG) enables fully-classical parties to generate 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 Delegated Quantum Computation#Classical Online Communication-No Quantum Communication|Secure Delegated Quantum Computation]] by just classical online communication and no quantum communication. It allows a fully classical Client to hide her data such that she instructs Server to generate random qubits hiding her inputs, outputs, circuit and perform quantum computation on it via [[Prepare and Send-Universal Blind Quantum Computation|UBQC]] or [[Verifiable Universal Blind Quantum Computation|VUBQC]]. It can also find use cases in other protocols like Quantum Money, Quantum Digital Signatures etc.. which needs a user to share his/her private quantum key over a quantum channel. | Secret Random Qubit Generator (SQRG) enables fully-classical parties to generate 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 Delegated Quantum Computation#Classical Online Communication-No Quantum Communication|Secure Delegated Quantum Computation]] by just classical online communication and no quantum communication. It allows a fully classical Client to hide her data such that she instructs Server to generate random qubits hiding her inputs, outputs, circuit and perform quantum computation on it via [[Prepare and Send-Universal Blind Quantum Computation|UBQC]] or [[Verifiable Universal Blind Quantum Computation|VUBQC]]. It can also find use cases in other protocols like Quantum Money, Quantum Digital Signatures etc.. which needs a user to share his/her private quantum key over a quantum channel. | ||
'''Tags:''' [[Two Party Protocols|Two Party]], [[Quantum Functionality|Quantum Functionality]], [[Universal Task|Universal Task | '''Tags:''' [[Two Party Protocols|Two Party]], [[Quantum Functionality|Quantum Functionality]], [[Universal Task|Universal Task]], [[Secure Delegated Quantum Computation#Classical Online Communication-No Quantum Communication|Secure Delegated Quantum Computation]], Classical Online Communication, [[Supplementary Information#Superposition|Superposition]], [[Supplementary Information#Collision Resistant Functions|Collision Resistant Functions]], [[Supplementary Information#Learning With Errors|Learning With Errors]] | ||
== 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 possible states. On the other hand, Client is supposed to know the classical description of the state. 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 tk. 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. 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 possible states. On the other hand, Client is supposed to know the classical description of the state. 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 tk. 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. Simple modifications to the protocol could achieve other similar sets of states.<br/><br/> |