Revision History for: Measurement Device Independent Quantum Digital Signature (MDI-QDS)

• 2026-06-07 at 22:22 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmetrisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [3] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  Stage 1 Distribution

  • Input Key Length ($L$), Threshold values ($s_a, s_v$), error threshold ($E_{tol}$), error rate parameter ($e$)
  • Output Seller: $S_B^0,S_B^1,S_V^0,S_V^1$ Buyer: $B^0,B^1$; Verifier: $V^0,V^1$
    • Key Distribution:

  1. For k = 0,1

     1. $S_B^k=B^k=$MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. $S_V^k=V^k=$MDI-KGP(Seller, Verifier, Arbitrator,k)
     • Symmetrisation

  2. For k = 0,1

     1. Buyer chooses $I\\\subset_R{1,2,…,L}, |I|=[L/2]$
     2. $\\\forall i\\\epsilon I$, Buyer sends Verifier $(k,i,B^k_i)$
     3. Verifier chooses $J\\\subset_R{1,2,…,L}, |J|=[L/2]$
     4. $\\\forall j\\\epsilon J$, Verifier sends Buyer $(k,j,V^k_j)$

  Stage 2 Messaging

  1. Input Seller: Message $m$, Private Key for $m$: $S^B_m,S^V_m$

  Output Buyer: accept or abort, Verifier: accept or abort

  • Signing:

  1. Seller sends Buyer (m,$S^B_m,S^V_m$)

  2. For l = 1,2,..,L, 1. If $l\\\in {1,2,…,L}-I$:

  3. Buyer counts the number of mismatches

     ($B^m_l!=S^m_l$), b=b+1

     m​), b=b+1

  4. If $l\\\epsilon J$: Buyer counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

  5. If $(b < s_aL/2)$&&$(v < s_aL/2)$, Buyer accepts m else he aborts

  • Transfer

  1. Buyer sends Verifier (m,$S^B_m,S^V_m$)

  2. For l = 1,2,..,L 1. If $l\\\epsilon {1,2,…,L}-J$

     • Verifier counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

     • If $l\\\in I $, Verifier counts the number of mismatches ($B^m_l!=S^m_l$), b=b+1
  3. If $(b < s_vL/2)$&&$(v < s_vL/2)$, Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses $s_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|a\\\rangle$
  2. Receiver chooses $r_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|b\\\rangle$
  3. Seller.send(Arbitrator,$|a\\\rangle$)
  4. Receiver.send(Arbitrator,$|b\\\rangle$)
  5. $|\\\Psi\\\rangle$=Arbitrator.BSM($|a\\\rangle$,$|b\\\rangle$)
  6. If ($|\\\Psi\\\rangle!={}$)&&($s_{\\\text{basis}}=r_{\\\text{basis}}$)
     1. $A^i_R(k)=a$
     2. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=Z$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle+|11\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle-|11\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle+|10\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|10\\\rangle)$) then $R^i(k)=\\\tilde b$
     3. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=X$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle+|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|+-\\\rangle+|-+\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle-|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|+-\\\rangle)$) then $R^i(k)=\\\tilde b$

  • Error rate calculation

  1. Seller and Buyer choose $I\\\subset_R{1,2,…,L}, |I|=e$
  2. $\\\forall i\\\epsilon I$, $E_k=\\\frac{1}{e}\\\sum_i(A^k_R(i)\\\oplus R^k(i))$
  3. If $E_k>E_{tol}$ then abort else
  4. return ($A^k_R,R^k$)

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS  does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. Puthoor, Ittoop Vergheese, Ryan Amiri, Petros Wallden, Marcos Curty, and Erika Andersson. ‘Measurement-Device-Independent Quantum Digital Signatures’. Physical Review A 94, no. 2 (August 2016). https://doi.org/10.1103/physreva.94.022328.
  2. Amiri, Ryan, Petros Wallden, Adrian Kent, and Erika Andersson. ‘Secure Quantum Signatures Using Insecure Quantum Channels’. Physical Review A 93, no. 3 (March 2016). https://doi.org/10.1103/physreva.93.032325.

      

     Lo, Hoi-Kwong, Marcos Curty, and Bing Qi. ‘Measurement-Device-Independent Quantum Key Distribution’. Physical Review Letters 108, no. 13 (March 2012). https://doi.org/10.1103/physrevlett.108.130503.

     Xu, Feihu, Bing Qi, Zhongfa Liao, and Hoi-Kwong Lo. ‘Long Distance Measurement-Device-Independent Quantum Key Distribution with Entangled Photon Sources’. Applied Physics Letters 103, no. 6 (August 2013). https://doi.org/10.1063/1.4817672.

     Roberts, G. L., M. Lucamarini, Z. L. Yuan, J. F. Dynes, L. C. Comandar, A. W. Sharpe, A. J. Shields, M. Curty, I. V. Puthoor, and E. Andersson. ‘Experimental Measurement-Device-Independent Quantum Digital Signatures’. Nature Communications 8, no. 1 (October 2017). https://doi.org/10.1038/s41467-017-01245-5.
• 2026-03-20 at 17:10 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmetrisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  Stage 1 Distribution

  • Input Key Length ($L$), Threshold values ($s_a, s_v$), error threshold ($E_{tol}$), error rate parameter ($e$)
  • Output Seller: $S_B^0,S_B^1,S_V^0,S_V^1$ Buyer: $B^0,B^1$; Verifier: $V^0,V^1$
    • Key Distribution:

  1. For k = 0,1

     1. $S_B^k=B^k=$MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. $S_V^k=V^k=$MDI-KGP(Seller, Verifier, Arbitrator,k)
     • Symmetrisation

  2. For k = 0,1

     1. Buyer chooses $I\\\subset_R{1,2,…,L}, |I|=[L/2]$
     2. $\\\forall i\\\epsilon I$, Buyer sends Verifier $(k,i,B^k_i)$
     3. Verifier chooses $J\\\subset_R{1,2,…,L}, |J|=[L/2]$
     4. $\\\forall j\\\epsilon J$, Verifier sends Buyer $(k,j,V^k_j)$

  Stage 2 Messaging

  • Input Seller: Message $m$, Private Key for $m$: $S^B_m,S^V_m$

  • Output Buyer: accept or abort, Verifier: accept or abort

    • Signing:

    1. Seller sends Buyer (m,$S^B_m,S^V_m$)

    2. For l = 1,2,..,L, 1. If $l\\\epsilon {1,2,…,L}-I$:

    3. Buyer counts the number of mismatches

       ($B^m_l!=S^m_l$), b=b+1

       m​), b=b+1

    4. If $l\\\epsilon J$: Buyer counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

    5. If $(b < s_aL/2)$&&$(v < s_aL/2)$, Buyer accepts m else he aborts

    • Transfer

    1. Buyer sends Verifier (m,$S^B_m,S^V_m$)

    2. For l = 1,2,..,L 1. If $l\\\epsilon {1,2,…,L}-J$

       • Verifier counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

       • If $l\\\epsilon I\\\$ – Verifier counts the number of mismatches ($B^m_l!=S^m_l\\\$), b=b+1

     

    1. If $(b < s_vL/2)$&&$(v < s_vL/2)$, Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses $s_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|a\\\rangle$
  2. Receiver chooses $r_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|b\\\rangle$
  3. Seller.send(Arbitrator,$|a\\\rangle$)
  4. Receiver.send(Arbitrator,$|b\\\rangle$)
  5. $|\\\Psi\\\rangle$=Arbitrator.BSM($|a\\\rangle$,$|b\\\rangle$)
  6. If ($|\\\Psi\\\rangle!={}$)&&($s_{\\\text{basis}}=r_{\\\text{basis}}$)
     1. $A^i_R(k)=a$
     2. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=Z$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle+|11\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle-|11\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle+|10\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|10\\\rangle)$) then $R^i(k)=\\\tilde b$
     3. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=X$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle+|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|+-\\\rangle+|-+\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle-|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|+-\\\rangle)$) then $R^i(k)=\\\tilde b$

  • Error rate calculation

  1. Seller and Buyer choose $I\\\subset_R{1,2,…,L}, |I|=e$
  2. $\\\forall i\\\epsilon I$, $E_k=\\\frac{1}{e}\\\sum_i(A^k_R(i)\\\oplus R^k(i))$
  3. If $E_k>E_{tol}$ then abort else
  4. return ($A^k_R,R^k$)

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. Puthoor, Ittoop Vergheese, Ryan Amiri, Petros Wallden, Marcos Curty, and Erika Andersson. ‘Measurement-Device-Independent Quantum Digital Signatures’. Physical Review A 94, no. 2 (August 2016). https://doi.org/10.1103/physreva.94.022328.
  2. Amiri, Ryan, Petros Wallden, Adrian Kent, and Erika Andersson. ‘Secure Quantum Signatures Using Insecure Quantum Channels’. Physical Review A 93, no. 3 (March 2016). https://doi.org/10.1103/physreva.93.032325.

      

     Lo, Hoi-Kwong, Marcos Curty, and Bing Qi. ‘Measurement-Device-Independent Quantum Key Distribution’. Physical Review Letters 108, no. 13 (March 2012). https://doi.org/10.1103/physrevlett.108.130503.

     Xu, Feihu, Bing Qi, Zhongfa Liao, and Hoi-Kwong Lo. ‘Long Distance Measurement-Device-Independent Quantum Key Distribution with Entangled Photon Sources’. Applied Physics Letters 103, no. 6 (August 2013). https://doi.org/10.1063/1.4817672.

     Roberts, G. L., M. Lucamarini, Z. L. Yuan, J. F. Dynes, L. C. Comandar, A. W. Sharpe, A. J. Shields, M. Curty, I. V. Puthoor, and E. Andersson. ‘Experimental Measurement-Device-Independent Quantum Digital Signatures’. Nature Communications 8, no. 1 (October 2017). https://doi.org/10.1038/s41467-017-01245-5.
• 2026-03-19 at 21:08 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmetrisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  Stage 1 Distribution

  • Input Key Length ($L$), Threshold values ($s_a, s_v$), error threshold ($E_{tol}$), error rate parameter ($e$)
  • Output Seller: $S_B^0,S_B^1,S_V^0,S_V^1$ Buyer: $B^0,B^1$; Verifier: $V^0,V^1$
    • Key Distribution:

  1. For k = 0,1

     1. $S_B^k=B^k=$MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. $S_V^k=V^k=$MDI-KGP(Seller, Verifier, Arbitrator,k)
     • Symmetrisation

  2. For k = 0,1

     1. Buyer chooses $I\\\subset_R{1,2,…,L}, |I|=[L/2]$
     2. $\\\forall i\\\epsilon I$, Buyer sends Verifier $(k,i,B^k_i)$
     3. Verifier chooses $J\\\subset_R{1,2,…,L}, |J|=[L/2]$
     4. $\\\forall j\\\epsilon J$, Verifier sends Buyer $(k,j,V^k_j)$

  Stage 2 Messaging

  • Input Seller: Message $m$, Private Key for $m$: $S^B_m,S^V_m$

  • Output Buyer: accept or abort, Verifier: accept or abort

    • Signing:

    1. Seller sends Buyer (m,$S^B_m,S^V_m$)

    2. For l = 1,2,..,L, 1. If $l\\\epsilon {1,2,…,L}-I$:

    3. Buyer counts the number of mismatches

       ($B^m_l!=S^m_l$), b=b+1

       m​), b=b+1

    4. If $l\\\epsilon J$: Buyer counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

    5. If $(b < s_aL/2)$&&$(v < s_aL/2)$, Buyer accepts m else he aborts

    • Transfer

    1. Buyer sends Verifier (m,$S^B_m,S^V_m$)

    2. For l = 1,2,..,L 1. If $l\\\epsilon {1,2,…,L}-J$

       • Verifier counts the number of mismatches ($V^m_l!=S^m_l$), v=v+1

       • If $l\\\epsilon I\\\$ – Verifier counts the number of mismatches ($B^m_l!=S^m_l\\\$), b=b+1

     

    3. If $(b < s_vL/2)$&&$(v < s_vL/2)$, Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses $s_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|a\\\rangle$
  2. Receiver chooses $r_{\\\text{basis}}\\\epsilon {X,Z}$ and generates $|b\\\rangle$
  3. Seller.send(Arbitrator,$|a\\\rangle$)
  4. Receiver.send(Arbitrator,$|b\\\rangle$)
  5. $|\\\Psi\\\rangle$=Arbitrator.BSM($|a\\\rangle$,$|b\\\rangle$)
  6. If ($|\\\Psi\\\rangle!={}$)&&($s_{\\\text{basis}}=r_{\\\text{basis}}$)
     1. $A^i_R(k)=a$
     2. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=Z$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle+|11\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|00\\\rangle-|11\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle+|10\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|10\\\rangle)$) then $R^i(k)=\\\tilde b$
     3. If ($s_{\\\text{basis}}=r_{\\\text{basis}}=X$)
        1. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle+|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|+-\\\rangle+|-+\\\rangle)$) then $R^i(k)=b$
        2. If ($|\\\Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|++\\\rangle-|–\\\rangle))||(|Psi\\\rangle=\\\frac{1}{\\\sqrt{2}}(|01\\\rangle-|+-\\\rangle)$) then $R^i(k)=\\\tilde b$

  • Error rate calculation

  1. Seller and Buyer choose $I\\\subset_R{1,2,…,L}, |I|=e$
  2. $\\\forall i\\\epsilon I$, $E_k=\\\frac{1}{e}\\\sum_i(A^k_R(i)\\\oplus R^k(i))$
  3. If $E_k>E_{tol}$ then abort else
  4. return ($A^k_R,R^k$)

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. Puthoor, Ittoop Vergheese, Ryan Amiri, Petros Wallden, Marcos Curty, and Erika Andersson. ‘Measurement-Device-Independent Quantum Digital Signatures’. Physical Review A 94, no. 2 (August 2016). https://doi.org/10.1103/physreva.94.022328.
  2. Amiri, Ryan, Petros Wallden, Adrian Kent, and Erika Andersson. ‘Secure Quantum Signatures Using Insecure Quantum Channels’. Physical Review A 93, no. 3 (March 2016). https://doi.org/10.1103/physreva.93.032325.

      

     Lo, Hoi-Kwong, Marcos Curty, and Bing Qi. ‘Measurement-Device-Independent Quantum Key Distribution’. Physical Review Letters 108, no. 13 (March 2012). https://doi.org/10.1103/physrevlett.108.130503.

     Xu, Feihu, Bing Qi, Zhongfa Liao, and Hoi-Kwong Lo. ‘Long Distance Measurement-Device-Independent Quantum Key Distribution with Entangled Photon Sources’. Applied Physics Letters 103, no. 6 (August 2013). https://doi.org/10.1063/1.4817672.

     Roberts, G. L., M. Lucamarini, Z. L. Yuan, J. F. Dynes, L. C. Comandar, A. W. Sharpe, A. J. Shields, M. Curty, I. V. Puthoor, and E. Andersson. ‘Experimental Measurement-Device-Independent Quantum Digital Signatures’. Nature Communications 8, no. 1 (October 2017). https://doi.org/10.1038/s41467-017-01245-5.
• 2026-02-26 at 08:23 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmetrisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  tage 1 Distribution

  • Input Key Length (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} ), Threshold values (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 s_a, s_v} ), error threshold (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 E_{tol}} ), error rate parameter (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 e} )
  • Output Seller: 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 S_B^0,S_B^1,S_V^0,S_V^1} 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 B^0,B^1} ; Verifier: 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^0,V^1}
    • Key Distribution:

  1. For k = 0,1
     1. 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 S_B^k=B^k=} MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. 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 S_V^k=V^k=} MDI-KGP(Seller, Verifier, Arbitrator,k)

  • • Symmetrisation

  1. For k = 0,1
     1. Buyer chooses 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 Isubset_R{1,2,…,L}, |I|=[L/2]}
     2. 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 iepsilon I} , Buyer sends Verifier 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 (k,i,B^k_i)}
     3. Verifier chooses 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 Jsubset_R{1,2,…,L}, |J|=[L/2]}
     4. 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 jepsilon 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 (k,j,V^k_j)}

  Stage 2 Messaging

  • Input Seller: Message 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} , Private Key for 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} : 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 S^B_m,S^V_m}
  • Output Buyer: accept or abort, Verifier: accept or abort
    • Signing:

  1. Seller sends Buyer (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-I}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
     2. 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 lepsilon J}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
  3. 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 < s_aL/2)} &&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 < s_aL/2)} , Buyer accepts m else he aborts

  • • Transfer

  1. Buyer sends Verifier (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-J}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
     2. 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 lepsilon I}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
  3. 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 < s_vL/2)} &&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 < s_vL/2)} , Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses 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 s_{text{basis}}epsilon {X,Z}} and generates 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 |arangle}
  2. Receiver chooses 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 r_{text{basis}}epsilon {X,Z}} and generates 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 |brangle}
  3. Seller.send(Arbitrator,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 |arangle} )
  4. Receiver.send(Arbitrator,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 |brangle} )
  5. 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 |Psirangle} =Arbitrator.BSM(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 |arangle} ,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 |brangle} )
  6. 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 |Psirangle!={}} )&&(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 s_{text{basis}}=r_{text{basis}}} )
     1. 1. 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 A^i_R(k)=a}
        2. 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 s_{text{basis}}=r_{text{basis}}=Z} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|00rangle+|11rangle))||(|Psirangle=frac{1}{sqrt{2}}(|00rangle-|11rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|01rangle+|10rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|10rangle)} ) then 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 R^i(k)=tilde b}
        3. 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 s_{text{basis}}=r_{text{basis}}=X} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle+|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|+-rangle+|-+rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle-|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|+-rangle)} ) then 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 R^i(k)=tilde b}

  • Error rate calculation

  1. Seller and Buyer choose 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 Isubset_R{1,2,…,L}, |I|=e}
  2. 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 iepsilon I} , 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 E_k=frac{1}{e}sum_i(A^k_R(i)oplus R^k(i))}
  3. 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 E_k>E_{tol}} then abort else
  4. return (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 A^k_R,R^k} )

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. AWKA (2015)
  2. Lo et al (2011)
  3. Xu et al (2013)
• 2026-02-16 at 00:55 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmetrisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  tage 1 Distribution

  • Input Key Length (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} ), Threshold values (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 s_a, s_v} ), error threshold (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 E_{tol}} ), error rate parameter (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 e} )
  • Output Seller: 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 S_B^0,S_B^1,S_V^0,S_V^1} 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 B^0,B^1} ; Verifier: 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^0,V^1}
    • Key Distribution:

  1. For k = 0,1
     1. 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 S_B^k=B^k=} MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. 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 S_V^k=V^k=} MDI-KGP(Seller, Verifier, Arbitrator,k)

  • • Symmetrisation

  1. For k = 0,1
     1. Buyer chooses 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 Isubset_R{1,2,…,L}, |I|=[L/2]}
     2. 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 iepsilon I} , Buyer sends Verifier 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 (k,i,B^k_i)}
     3. Verifier chooses 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 Jsubset_R{1,2,…,L}, |J|=[L/2]}
     4. 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 jepsilon 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 (k,j,V^k_j)}

  Stage 2 Messaging

  • Input Seller: Message 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} , Private Key for 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} : 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 S^B_m,S^V_m}
  • Output Buyer: accept or abort, Verifier: accept or abort
    • Signing:

  1. Seller sends Buyer (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-I}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
     2. 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 lepsilon J}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
  3. 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 < s_aL/2)} &&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 < s_aL/2)} , Buyer accepts m else he aborts

  • • Transfer

  1. Buyer sends Verifier (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-J}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
     2. 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 lepsilon I}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
  3. 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 < s_vL/2)} &&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 < s_vL/2)} , Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses 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 s_{text{basis}}epsilon {X,Z}} and generates 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 |arangle}
  2. Receiver chooses 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 r_{text{basis}}epsilon {X,Z}} and generates 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 |brangle}
  3. Seller.send(Arbitrator,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 |arangle} )
  4. Receiver.send(Arbitrator,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 |brangle} )
  5. 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 |Psirangle} =Arbitrator.BSM(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 |arangle} ,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 |brangle} )
  6. 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 |Psirangle!={}} )&&(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 s_{text{basis}}=r_{text{basis}}} )
     1. 1. 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 A^i_R(k)=a}
        2. 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 s_{text{basis}}=r_{text{basis}}=Z} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|00rangle+|11rangle))||(|Psirangle=frac{1}{sqrt{2}}(|00rangle-|11rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|01rangle+|10rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|10rangle)} ) then 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 R^i(k)=tilde b}
        3. 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 s_{text{basis}}=r_{text{basis}}=X} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle+|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|+-rangle+|-+rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle-|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|+-rangle)} ) then 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 R^i(k)=tilde b}

  • Error rate calculation

  1. Seller and Buyer choose 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 Isubset_R{1,2,…,L}, |I|=e}
  2. 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 iepsilon I} , 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 E_k=frac{1}{e}sum_i(A^k_R(i)oplus R^k(i))}
  3. 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 E_k>E_{tol}} then abort else
  4. return (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 A^k_R,R^k} )

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. AWKA (2015)
  2. Lo et al (2011)
  3. Xu et al (2013)
• 2026-02-10 at 22:53 by kimworrall
  Show/Hide Content

  implements Quantum Digital Signature

  Introduction

  ---

  The example protocol achieves the functionality of Quantum Digital Signature (QDS) by allowing exchange of messages using the procedure studied in Prepare and Measure Quantum Digital Signature but without trusting one’s measurement devices, thus making the protocol device independent. It uses the security proof of MDI-QKD to the QDS scheme for insecure channels (1). This scheme involves three parties and is designed for signing one bit and the authors suggest that longer messages can be signed by iterating the same process. All three properties that define QDS i.e. non-repudiation, transferability and unforgeability are implied by the protocol.

  Related Paper(s)

  ---

  Measurement-Device-Independent Quantum Digital Signatures

  Outline

  ---

  Quantum Digital Signature protocols can be separated into two stages: the distribution stage, where quantum public keys are sent to all recipients, and the messaging stage, where classical messages are 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.
  The following protocol consists of only quantum communication in the distribution phase and only classical communication in the messaging phase. It uses the protocol for QDS with insecure channels (1) and replaces KGP (Key generation protocol) with Measurement Device Independent KGP (MDI-KGP). Distribution phase can be divided into the following steps:

  • Key Distribution: Seller uses MDI-KGP twice with buyer and verifier, to generate two different keys with each, one for message bit 0 and one for message bit 1. Seller’s signature for a particular message bit is a conjugation/concatenation of corresponding key for message bit sent to the buyer and the verifier. Below is an overview of MGI-KGP extracted from MDI-QKD (page to be visited in case more explanation is required)
    • MDI-KGP: MDI-KGP consists of only quantum communication part from MDI-QKD protocol in (2). This protocol requires an untrusted third party sitting in the middle of the participating parties, arbitrator. The following steps are performed with seller and each receiver, pairwise for each possible bit (0 and 1). Seller and receiver, both separately prepare a state in a randomly chosen basis (of the two chosen bases, say rectilinear (X basis) and diagonal (Z basis)), and send it to the arbitrator. The arbitrator performs Bell State Measurement on the two incoming states. A successful BSM entangles the two states and the outcome of the measurement is one of the four Bell States, which is declared by the arbitrator over public channel. This process is repeated until sifting condition is met. In sifting, seller and receiver then exchange the preparation basis chosen for each event, which is neglected if the basis is mismatched. If matched then, depending on the basis chosen, data (classical information of their own states/ classical bits) corresponding to each event is classified into two sets. This is repeated unless cardinality of the two sets is above a certain threshold number of elements. The receiver flips his bits (set elements) for each event according to the table shown in Pseudo Code. It is done to correlate seller’s bits with receiver’s bits. This marks the end of Sifting. Finally, one of the sets is used for error correction in MDI-QKD (not the concern of this protocol), while the other set is divided into two parts, one to be used as the code key and the other, to calculate the error rate. If error rate is greater than the tolerance value decided, the protocol is aborted by both parties. The signature/private key of seller for a particular message bit is the concatenation of both buyer and verifier’s code keys corresponding to that bit.
  • Symmetrisation: Buyer and Verifier exchange half of their MGI-KGP keys over MDI-QKD link. These become the final keys of the recipients. This prevents a dishonest seller succeed in cheating by sending dissimilar public keys to the receiver and makes the protocol secure against repudiation. Thus ends the distribution phase.

  Similarly, Messaging Phase is divided into the following steps:

  • Signing: Sender sends desired message and the corresponding signature to the desired receiver (called buyer). Buyer checks for mismatches, first with his half of the key, received directly from Seller and then, with verifier’s half shared with him during symmterisation. If there are fewer mismatches than the decided threshold (to check for repudiation, determined by experimental parameters) then buyer accepts the signature.
  • Transfer: Buyer forwards the same message and private key to the other receiver (called verifier) who compares it with his key for this message bit in the same way as the buyer, but with a different threshold value (to check for forgery and repudiation).

  Assumptions

  ---

  • There exists authenticated classical channels between seller and buyer, and, seller and verifier.
  • Receiver and verifier share a MDI-QKD link, used to transmit classical messages in full secrecy.
  • Adversary is allowed to perform coherent attacks, which is the most general class of attacks QKD protocols are vulnerable to, due to experimental realisation.

  Requirements

  ---

  • Network Stage: Prepare and Measure
  • Authenticated quantum channel
  • Authenticated classical channel
  • Estimated parameters (for security level of order $10^{-5}$ )
    • Signature length:$ 10^{6}$ for each message bit 0 and 1.
    • Transmission distance: 50km
    • Estimated time to generate raw keys: 93 minutes (can be improved by using detectors with better efficiency)
  • MDI-QKD setup (without error correction and privacy amplification)

  Notation

  ---

  No content has been added to this section, yet!

  Properties

  ---

  • The strings generated by Sender and Receiver are free from detector side channel attacks as one does not trust measurement devices.
  • Implementation of long distance MDI-QKD [Measurement Device Independent Quantum Digital Signature (MDI-QDS)#References|(3)] employs establishes long distance QDS protocol without side channel attacks
  • It removes all detector side-channel attacks
  • It is valid against repudiation and forging attacks

  Technical Description

  ---

  tage 1 Distribution

  • Input Key Length (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} ), Threshold values (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 s_a, s_v} ), error threshold (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 E_{tol}} ), error rate parameter (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 e} )
  • Output Seller: 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 S_B^0,S_B^1,S_V^0,S_V^1} 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 B^0,B^1} ; Verifier: 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^0,V^1}
    • Key Distribution:

  1. For k = 0,1
     1. 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 S_B^k=B^k=} MDI-KGP(Seller, Buyer, Arbitrator,k)
     2. 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 S_V^k=V^k=} MDI-KGP(Seller, Verifier, Arbitrator,k)

  • • Symmetrisation

  1. For k = 0,1
     1. Buyer chooses 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 Isubset_R{1,2,…,L}, |I|=[L/2]}
     2. 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 iepsilon I} , Buyer sends Verifier 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 (k,i,B^k_i)}
     3. Verifier chooses 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 Jsubset_R{1,2,…,L}, |J|=[L/2]}
     4. 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 jepsilon 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 (k,j,V^k_j)}

  Stage 2 Messaging

  • Input Seller: Message 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} , Private Key for 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} : 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 S^B_m,S^V_m}
  • Output Buyer: accept or abort, Verifier: accept or abort
    • Signing:

  1. Seller sends Buyer (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-I}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
     2. 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 lepsilon J}
        1. Buyer counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
  3. 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 < s_aL/2)} &&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 < s_aL/2)} , Buyer accepts m else he aborts

  • • Transfer

  1. Buyer sends Verifier (m,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 S^B_m,S^V_m} )
  2. For l = 1,2,..,L
     1. 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 lepsilon {1,2,…,L}-J}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), v=v+1
     2. 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 lepsilon I}
        1. Verifier counts the number of mismatches (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^m_l!=S^m_l} ), b=b+1
  3. 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 < s_vL/2)} &&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 < s_vL/2)} , Verifier accepts m else he aborts

  Subroutine: MDI-KGP(Seller, Receiver R, Arbitrator,i)

  • For k=0,L

  1. Seller chooses 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 s_{text{basis}}epsilon {X,Z}} and generates 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 |arangle}
  2. Receiver chooses 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 r_{text{basis}}epsilon {X,Z}} and generates 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 |brangle}
  3. Seller.send(Arbitrator,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 |arangle} )
  4. Receiver.send(Arbitrator,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 |brangle} )
  5. 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 |Psirangle} =Arbitrator.BSM(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 |arangle} ,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 |brangle} )
  6. 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 |Psirangle!={}} )&&(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 s_{text{basis}}=r_{text{basis}}} )
     1. 1. 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 A^i_R(k)=a}
        2. 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 s_{text{basis}}=r_{text{basis}}=Z} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|00rangle+|11rangle))||(|Psirangle=frac{1}{sqrt{2}}(|00rangle-|11rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|01rangle+|10rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|10rangle)} ) then 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 R^i(k)=tilde b}
        3. 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 s_{text{basis}}=r_{text{basis}}=X} )
           1. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle+|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|+-rangle+|-+rangle)} ) then 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 R^i(k)=b}
           2. 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 |Psirangle=frac{1}{sqrt{2}}(|++rangle-|–rangle))||(|Psirangle=frac{1}{sqrt{2}}(|01rangle-|+-rangle)} ) then 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 R^i(k)=tilde b}

  • Error rate calculation

  1. Seller and Buyer choose 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 Isubset_R{1,2,…,L}, |I|=e}
  2. 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 iepsilon I} , 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 E_k=frac{1}{e}sum_i(A^k_R(i)oplus R^k(i))}
  3. 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 E_k>E_{tol}} then abort else
  4. return (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 A^k_R,R^k} )

  • For more detail on error rate and MDI-KGP Pseudo code, refer MDI-QKD

  Experimental Implementations

  ---

  No content has been added to this section, yet!

  Further Information

  ---

  MDI-QDS is so far the best Prepare and Measure Network Stage QDS protocol. It does not rely on the measurement devices and is easy from implementation point of view. Unlike classical schemes, this protocol does not assume a trusted arbitrator. As the platform of widely implemented MDI-QKD is available, MDI-QDS can be implemented most efficiently and provides the best security in the QDS protocols discovered so far. Another approach would be to adapt DI-QKD for key generation. Here one would neither trust the measurement devices nor the source. As seller and buyer both act as an adversary in QDS protocols, we do not want depend on our state preparation devices either. This has not been studied yet due to as QDS protocols discovered so far yet do not match up to the efficiency of classical and post-quantum digital signature schemes in terms of signing time, key length, etc.

  • Theoretical Papers

  1. Guang et al (2011) A scheme for untrusted arbitartor like MDI-QDS, but trusts its measurement devices

  • Experimental Papers

  1. Roberts et al (2017) Implementation of the example protocol

  References

  ---

  1. AWKA (2015)
  2. Lo et al (2011)
  3. Xu et al (2013)

← Back to post