implements Secure Client-Server Delegated Computation
The example protocol[1] 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 instruct a 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.
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. 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,
Stage 1 – Preimages superposition:
Requirements:
Public: A family $\\\mathcal{F}={f_k : {0,1}^n \\\rightarrow {0,1}^m }$ 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: $\\\alpha=(\\\alpha_1,\\\cdots,\\\alpha_{n-1})$ where $\\\alpha_i\\\leftarrow{0,1}^3$, and runs the algorithm $(k,t_k) \\\leftarrow \\\text{Gen}_{\\\mathcal{F}}(1^n)$. The $\\\alpha$ and $k$ are public inputs (known to both parties), while $t_k$ is the ”private” input of the Client.
Stage 2 – Squeezing
Output: If the protocol is run honestly, when there is no abort, the state that Server has is $+_{\\\theta}$, where the Client (only) knows the classical description.
No content has been added to this section, yet!
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.
Glossary (informal):
implements Secure Client-Server Delegated Computation
The example protocol[1] 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 instruct a 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.
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. 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,
Stage 1 – Preimages superposition:
Requirements:
Public: A family $\\\mathcal{F}={f_k : {0,1}^n \\\rightarrow {0,1}^m }$ 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: $\\\alpha=(\\\alpha_1,\\\cdots,\\\alpha_{n-1})$ where $\\\alpha_i\\\leftarrow{0,1}^3$, and runs the algorithm $(k,t_k) \\\leftarrow \\\text{Gen}_{\\\mathcal{F}}(1^n)$. The $\\\alpha$ and $k$ are public inputs (known to both parties), while $t_k$ is the ”private” input of the Client.
Stage 2 – Squeezing
Output: If the protocol is run honestly, when there is no abort, the state that Server has is $+_{\\\theta}$, where the Client (only) knows the classical description.
No content has been added to this section, yet!
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.
Glossary (informal):
implements Secure Client-Server Delegated Computation
The example protocol[1] 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 instruct a 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.
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. 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,
Stage 1 – Preimages superposition:
Requirements:
Public: A family $\\\mathcal{F}={f_k : {0,1}^n \\\rightarrow {0,1}^m }$ 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: $\\\alpha=(\\\alpha_1,\\\cdots,\\\alpha_{n-1})$ where $\\\alpha_i\\\leftarrow{0,1}^3$, and runs the algorithm $(k,t_k) \\\leftarrow \\\text{Gen}_{\\\mathcal{F}}(1^n)$. The $\\\alpha$ and $k$ are public inputs (known to both parties), while $t_k$ is the ”private” input of the Client.
Stage 2 – Squeezing
Output: If the protocol is run honestly, when there is no abort, the state that Server has is $+_{\\\theta}$, where the Client (only) knows the classical description.
No content has been added to this section, yet!
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.
Glossary (informal):
implements Secure Client-Server Delegated Computation
The example protocol[1] 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 instruct a 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.
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. 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,
No content has been added to this section, yet!
s[TBA]
s[TBA]
No content has been added to this section, yet!
No content has been added to this section, yet!
s[TBA]
implements Secure Client-Server Delegated Computation
The example protocol[1] 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 instruct a 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.
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. 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,
No content has been added to this section, yet!
s[TBA]
s[TBA]
No content has been added to this section, yet!
No content has been added to this section, yet!
s[TBA]