Gottesman and Chuang Quantum Digital Signature: Difference between revisions
m (→Outline) |
|||
Line 1: | Line 1: | ||
== Functionality Description== | == Functionality Description== | ||
Digital Signatures (QDS) allow the exchange of classical messages from sender to multiple recipients, with a guarantee that the signature has come from a genuine sender. Additionally, it comes with the properties of (i) [[transferability]] i.e. messages with DS can be forwarded from one recipient to another such that DS is verifiable to have come from the original sender, (ii) [[non-repudiation]] i.e at any stage after sending the message to one recipient, sender cannot deny having sent the message and corresponding DS, and (iii) [[unforgeability]] i.e. a dishonest recipient cannot alter or fake the sender's DS and forward it to other recipients successfully. For simplicity, most protocols take into account the case of one sender and two recipients (Seller, buyer and verifier) exchanging single-bit classical messages.<br/> | Digital Signatures (QDS) allow the exchange of classical messages from sender to multiple recipients, with a guarantee that the signature has come from a genuine sender. Additionally, it comes with the properties of (i) [[transferability]] i.e. messages with DS can be forwarded from one recipient to another such that DS is verifiable to have come from the original sender, (ii) [[non-repudiation]] i.e at any stage after sending the message to one recipient, sender cannot deny having sent the message and corresponding DS, and (iii) [[unforgeability]] i.e. a dishonest recipient cannot alter or fake the sender's DS and forward it to other recipients successfully. For simplicity, most protocols take into account the case of one sender and two recipients (Seller, buyer and verifier) exchanging single-bit classical messages.<br/> Such protocols require parties to store quantum states for comparison at a later stage. | ||
'''Tags:''' [[Multi Party Protocols|Multi Party (three)]], [[Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[Specific Task|Specific Task]], [[Quantum Digital Signature]], [[Prepare and Measure Quantum Digital Signature]], [[Measurement Device Independent Quantum Digital Signature (MDI-QDS)]] | '''Tags:''' [[Multi Party Protocols|Multi Party (three)]], [[Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[Specific Task|Specific Task]], [[Quantum Digital Signature]], [[Prepare and Measure Quantum Digital Signature]], [[Measurement Device Independent Quantum Digital Signature (MDI-QDS)]] |
Revision as of 12:00, 7 November 2018
Functionality Description
Digital Signatures (QDS) allow the exchange of classical messages from sender to multiple recipients, with a guarantee that the signature has come from a genuine sender. Additionally, it comes with the properties of (i) transferability i.e. messages with DS can be forwarded from one recipient to another such that DS is verifiable to have come from the original sender, (ii) non-repudiation i.e at any stage after sending the message to one recipient, sender cannot deny having sent the message and corresponding DS, and (iii) unforgeability i.e. a dishonest recipient cannot alter or fake the sender's DS and forward it to other recipients successfully. For simplicity, most protocols take into account the case of one sender and two recipients (Seller, buyer and verifier) exchanging single-bit classical messages.
Such protocols require parties to store quantum states for comparison at a later stage.
Tags: Multi Party (three), Quantum Enhanced Classical Functionality, Specific Task, Quantum Digital Signature, Prepare and Measure Quantum Digital Signature, Measurement Device Independent Quantum Digital Signature (MDI-QDS)
Requirements
- Network Stage: Quantum Memory
- Relevant Network Parameters:
- Benchmark values:
Use Case
Online Transactions, Signing Marksheets
Example:
Outline
Quantum Digital Signature (QDS) protocols can be separated into two stages: the distribution stage, where quantum signals (public keys) are sent to all recipients, and the messaging stage, where classical messages are signed, sent and verified. Here, we take the case of three parties, one sender (referred to as seller) and two receivers (buyer and verifier) sharing a one bit message. Distribution phase can be divided into the following steps:
- Key Distribution:
Figure
Similarly, Messaging Phase is divided into the following steps:
- Signing:
- Transfer:
Properties
- The protocol-
- involves three parties (Seller, Buyer, Verifier) exchanging one-bit classical messages.
- Requires BB84 QKD setup, authenticated quantum and classical channels
- assumes maximum number of participating parties are honest. In the present case at least two parties are honest.
- provides information-theoretic security
- provides security against repudiation, i.e. the probability that seller succeeds in making buyer and seller disagree on the validity of her sent quantum signature decays exponentially with L, as stated by the formula .
- provides security against forgery, i.e. any recipient (verifier) with high probability rejects any message which was not originally sent by the seller herself. Forging probability is given by the formula, , where is 3/8 (calculated using uncertainty principle).
Pseudo Code
- Notations Used:
- L: Length of keys used
- : Threshold value for signing
- : Threshold value for verification
- : Quantum Public key for message k
- : Classical Private key for classical one-bit message k
- : Classical description of Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle l^{th}} qubit in
- : Buyer's Eliminated Signature for message m
- : Verifier's Eliminated Signature for message m
- : Buyer’s random bit to determine the measurement basis of qubit in
- : Verifier’s random bit to determine the measurement basis of qubit in
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle m_{b^k_l}} : measurement outcome of Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle b^k_l}
Stage 1 Distribution
- Input L
- Output Seller: ; Buyer: ; Verifier:
- Key Distribution:
- For k = 0,1
- Seller prepares quantum public key , where Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \beta^k_l\in_R \{0,1,+,-\}}
- She sends Buyer (k,)
- She sends Verifier (k,)
- State Elimination:
- For k = 0,1
- For l = 1,2,...,L
- Buyer chooses
- If Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle b^k_l=0} , Buyer measures his qubit in X basis
- If Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle b^k_l=0} , Buyer measures his qubit in Z basis
- return
- For l = 1,2,...,L
- Verifier repeats steps 2(a)-2(b) with randomly chosen basis Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle v^k_l} to get his eliminated signature elements
- Symmetrisation
- For k = 0,1
- Buyer chooses I
- , Buyer sends Verifier
- Verifier chooses J
- , Verifier sends Buyer
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \forall j\epsilon J} Buyer replaces
- Verifier replaces
- For k = 0,1
Stage 2 Messaging
- Input Seller: Message m, Private Key for m:
- Output Buyer: accept or abort, Verifier: accept or abort
- Signing: ’mismatch’ is when Buyer finds an eliminated signature element in Seller’s private key
- Seller sends Buyer (m,)
- For l = 1,2,..,L
- Buyer counts the number of mismatches () and returns
- If , Buyer accepts m else he aborts
- Transfer
- Buyer sends Verifier (m,)
- For l = 1,2,....,L
- Verifier counts the number of mismatches () and returns
- If , Verifier accepts m else he aborts
Discussion
- Theoretical Papers
- WDKA (2015) above example
- GC-QDS (2001) uses quantum one way function f(); Private keys: classical input x, Public keys: quantum output f(x). Requires quantum memory, quantum one way function, authenticated quantum and classical channels, SWAP Test (universal quantum computer). Unconditionally Secure. Network Stage: Quantum Memory
- ACJ (2006) discusses coherent states comparison with a QDS scheme outlined in the last section. Protocol uses the same protocol as (2) but replaces qubits with coherent states, thus replacing SWAP-Test with Coherent State Comparison. Additionally, it also requires quantum memory, authenticated quantum and classical channels, multiports. Unconditionally Secure, Network Stage: Quantum Memory
- DWA (2013) first QDS scheme without quantum memory based on (3). Requires Coherent States, authenticated quantum and classical channels, multiports, Unambiguous State Discrimination (USD) (State Elimination), no symmetrisation required. Unconditionally Secure. Network Stage: Prepare and Measure
- AL (2014) Establishes coherent state mapping of (2). Replaces SWAP Test with beam splitters. Uses Unambiguous State Discrimination (USD) (State Elimination). Requires Phase encoded Coherent states, Balanced Beam Splitters. No explicit security proof provided. Network Stage: Prepare and Measure
- AWA (2015) security proof for generalisation of WDKA (2015) and DWA (2013) to more than two recipients case.
- YFC (2016) first QDS scheme without authenticated (trusted) quantum channels. Demonstrates one protocol with two implementation, two copies of single photon method and decoy state method. First uses single qubit photons in three bases; Private key: classical description of states, Public key: pair of non-orthogonal states in any two of the three bases. Requires authenticated classical channels, polarisation measurement in three bases, Unambiguous State Discrimination (USD) (State Elimination), uses quantum correlations to check authentication. Decoy State method uses phase-randomised weak coherent states, 50:50 Beam Splitter (BS), Unconditionally Secure Network Stage: Prepare and Measure.
- AWKA (2015) QDS scheme without authenticated quantum channels using parameter estimation phase. Uses a Key Generations Protocol (KGP) where noise threshold for Seller-Buyer and Seller-Verifier is better than when distilling secret key from QKD. Seller sends different key to Buyer and Verifier using KGP. This anamoly is justifiable due to symmetrisation.Requires authenticated classical channels, decoy state BB84 QKD setup. Unconditionally Secure Network Stage: Prepare and Measure.
- MH (2016) security proof for generalisation of AWKA (2015) to more than two recipients case.
- WCRZ (2015) demonstrates sending multi-bit classical messages using AWKA (2015) or other similar protocols.
- SWZY (2017) Discusses an attack and suggests corrections on existing QDS scheme using single qubit rotations. Protocol uses rotation, qubits, one-way hash function; Private keys: angle of rotation, Public keys: string of rotated quantum states. Requires random number generator, one-way hash function, quantum memory, key distribution. Computationally Secure, Third Network Stage (Quantum Memory)
- Experimental Papers