Quantum Token: Difference between revisions

From Quantum Protocol Zoo
Jump to navigation Jump to search
(Charlie moved page Unforgeable Quantum Token to Quantum Token)
Tag: New redirect
 
(Removed redirect to Quantum Token)
Tag: Removed redirect
Line 1: Line 1:
#REDIRECT [[Quantum Token]]
Money is issued by one party (bank) to a prover (client) such that when he presents it to a verifier
(merchant), he/she is satisfied that the money presented by client comes from the bank. It comes
with the property of [[unforgeability]] and [[transferrability]]. Unforgeability means that there should exist
no method to produce an identical copy by anyone but the bank, and transferrability, allows that this
money can be used by the verifier as a client himself in the next round.</br>
 
'''Tags:''' [[:Category: Multi Party Protocols|Multi Party Protocols]], non local games, [[:Category: Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[:Category: Specific Task|Specific Task]]
[[Category: Prepare and Measure Network Stage]]
[[Category: Specific Tasks]]
[[Category: Quantum Enhanced Classical Functionality]]
[[Category: Multi Party Protocols]]
 
==Assumptions==
* Money is physically transferred to the holders
* If <math>F^{cv}_{tol} > (1+1/\sqrt{2})/2</math> , a dishonest user is exponentially unlikely to be authenticated by two independent verifiers (success in cheating to use same ticket for two independent verifiers by measuring in intermediate basis between the two bases, asked by the verifiers individually).
 
==Outline==
The protocol can be divided into three parts
* '''Preparation''' Bank prepares few rows of qubit-pairs chosen from two different non-orthogonal sets of basis. Each pair has at least one state from both bases, such that the qubit pair states are non-orthogonal. It associates each such chosen set with a serial number and shares the classical information about the choices for respective serial number with trusted merchants.
* '''Interaction''' This step involves challenge questions by verifier to prove that he has a valid token, by playing part of a [[non-local game]]. In this game, the merchant asks client to measure in one of the two bases in from which the qubit pairs were chosen. As each qubit pair contains at least one state from each basis chosen, after the measurement one of the qubits (encoded in the basis chosen by the merchant) would give the correct result.
* '''Transaction''' The merchant compares this qubit outcome whose encoding basis matches with merchant's basis for the game. Merchant accepts the ticket if the ratio of number of valid outcomes to total number of qubits measured is more than or equal to a certain threshold fidelity value.
 
==Notation==
*<math>N=n*r*2</math>, total number of qubits
*<math>F^{cv}_{tol}:</math> is the tolerance fidelity set by the verifiers
*<math>F^{cv}_{tol}(r*2) < F^{exp}:</math> where <math> F^{exp}</math> is the average experimental fidelity
 
==Hardware Requirements==
'''Network Stage''': [[:Category: Prepare and Measure Network Stage|Prepare and Measure]]
 
==Properties==
* Challenge questions reveal no information about the token
* No quantum communication is needed
* Tokens are remotely verifiable/ classically verifiable
* A dishonest user is exponentially unlikely to succeed with probability at most, <math>p_d = e^{ND}(2F^{cv}_{tol}-1||2/3)</math>, where <math>(2F^{cv}_{tol}-1)</math> is the fraction of qubits to be copied in order to forge a ticket and 2/3 is the average fidelity of copies produced by optimal cloning map, D being relative entropy.
* An honest user is exponentially likely to succeed with probability at least, <math>p^{cv}_h = e^{ND}(F^{exp}||F^{cv}_{tol})</math>
 
==Pseudo-Code==
'''Input:''' (Bank) <math>n*r*2</math>, Qubit-pairs <math>\epsilon_R\{(0,+),(0,-),(1,+),(1,-),(+,0),(-,0),(+,1),(-,1)\}</math> </br>
'''Output:''' (Merchant) accept or reject</br>
<u>'''Stage 1'''</u> Preparation </br>
# Bank prepares Token<math>_S</math> with <math>n*r*2</math> qubit pairs
# Bank distributes tickets to clients
# Bank distributes the classical record of states corresponding to S to trusted
verifiers (merchants)
<u>'''Stage 2'''</u> Interaction </br>
# Merchant asks client to measure a few qubit-pairs(say, a row) in a randomly chosen basis M \epsilon_R \{X,Z\}
# Client returns measurement outcome (m) for all qubit pairs asked to measure
<u>'''Stage 3'''</u> Transaction </br>
# Merchant compares the number of qubit pairs with the valid outcome for the qubit which was
generated in M basis as k.
# Merchant accepts if <math>k/(r*2)>F^{cv}_{tol}</math> else he rejects
 
==Further Information==
 
<div style='text-align: right;'>''*contributed by Shraddha Singh''</div>

Revision as of 11:03, 25 April 2019

Money is issued by one party (bank) to a prover (client) such that when he presents it to a verifier (merchant), he/she is satisfied that the money presented by client comes from the bank. It comes with the property of unforgeability and transferrability. Unforgeability means that there should exist no method to produce an identical copy by anyone but the bank, and transferrability, allows that this money can be used by the verifier as a client himself in the next round.

Tags: Multi Party Protocols, non local games, Quantum Enhanced Classical Functionality, Specific Task

Assumptions

  • Money is physically transferred to the holders
  • If , a dishonest user is exponentially unlikely to be authenticated by two independent verifiers (success in cheating to use same ticket for two independent verifiers by measuring in intermediate basis between the two bases, asked by the verifiers individually).

Outline

The protocol can be divided into three parts

  • Preparation Bank prepares few rows of qubit-pairs chosen from two different non-orthogonal sets of basis. Each pair has at least one state from both bases, such that the qubit pair states are non-orthogonal. It associates each such chosen set with a serial number and shares the classical information about the choices for respective serial number with trusted merchants.
  • Interaction This step involves challenge questions by verifier to prove that he has a valid token, by playing part of a non-local game. In this game, the merchant asks client to measure in one of the two bases in from which the qubit pairs were chosen. As each qubit pair contains at least one state from each basis chosen, after the measurement one of the qubits (encoded in the basis chosen by the merchant) would give the correct result.
  • Transaction The merchant compares this qubit outcome whose encoding basis matches with merchant's basis for the game. Merchant accepts the ticket if the ratio of number of valid outcomes to total number of qubits measured is more than or equal to a certain threshold fidelity value.

Notation

  • , total number of qubits
  • is the tolerance fidelity set by the verifiers
  • where is the average experimental fidelity

Hardware Requirements

Network Stage: Prepare and Measure

Properties

  • Challenge questions reveal no information about the token
  • No quantum communication is needed
  • Tokens are remotely verifiable/ classically verifiable
  • A dishonest user is exponentially unlikely to succeed with probability at most, , where is the fraction of qubits to be copied in order to forge a ticket and 2/3 is the average fidelity of copies produced by optimal cloning map, D being relative entropy.
  • An honest user is exponentially likely to succeed with probability at least,

Pseudo-Code

Input: (Bank) , Qubit-pairs
Output: (Merchant) accept or reject
Stage 1 Preparation

  1. Bank prepares Token with qubit pairs
  2. Bank distributes tickets to clients
  3. Bank distributes the classical record of states corresponding to S to trusted

verifiers (merchants) Stage 2 Interaction

  1. Merchant asks client to measure a few qubit-pairs(say, a row) in a randomly chosen basis M \epsilon_R \{X,Z\}
  2. Client returns measurement outcome (m) for all qubit pairs asked to measure

Stage 3 Transaction

  1. Merchant compares the number of qubit pairs with the valid outcome for the qubit which was

generated in M basis as k.

  1. Merchant accepts if else he rejects

Further Information

*contributed by Shraddha Singh