BB84 Quantum Key Distribution
The BB84 protocol implements the task of Quantum Key Distribution (QKD). The protocol enables two parties, Sender and Receiver, to establish a classical secret key by preparing and measuring qubits. The output of the protocol is a classical secret key which is completely unknown to any third party, namely an eavesdropper.
Tags: Two Party, Quantum Enhanced Classical Functionality, Specific Task,Quantum Key Distribution, Device Independent QKD,
Assumptions
- We assume the existence of an authenticated public classical channel between the two parties
- We assume synchronous network between parties
- We assume security from coherent attacks
Outline
The protocol shares a classical between two parties, sender and receiver. The BB84 quantum key distribution protocol is composed by the following steps:
- Distribution: This step involves preparation, exchange and measurement of quantum states. For each round of the distribution phase, Sender randomly chooses a basis (a pair of orthogonal states) out of two available bases (X and Z). She then randomly chooses one of the two states and prepares the corresponding quantum state in the chosen basis. She sends the prepared state to Receiver. Upon receiving the state, Receiver announces that he received the state and randomly chooses to measure in the either of the two available bases (X or Z). The outcomes of the measurements give Receiver a string of classical bits. The two parties repeat the above procedure times so that at the end of the distribution phase each of them holds an -bit string.
- Sifting: Both parties publicly announce their choices of basis and compare them. They discard the rounds in which Receiver measured in a different basis than the one prepared by Sender.
- Parameter estimation: Both parties use a fraction of the remaining rounds (in which both measured in the same basis) in order to estimate the quantum bit error rate (QBER).
- Error correction: Both together, choose a classical error correcting code and publicly communicate in order to correct their string of bits. At the end of this phase both parties hold the same bit-string.
- Privacy amplification: Both use an extractor on the previously established string to generate a smaller but completely secret string of bits, which is the final key.
Hardware Requirements
- Network Stage: Prepare and Measure
- Relevant Network Parameters: (see Prepare and Measure)
- Benchmark values:
- Minimum number of rounds ranging from to depending on the network parameters, for commonly used secure parameters.
- , taking a depolarizing model as benchmark. Parameters satisfying are sufficient.
- requires Authenticated classical channel, Random number generator.
Notation
- number of total rounds of the protocol.
- 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 \ell} size of the secret key.
- bits of input of Sender and Receiver, respectively, that define the measurement basis.
- bits of output of Sender and Receiver, respectively.
- final key of Sender and Receiver, respectively.
- is the quantum bit error rate QBER in the basis.
- is the quantum bit error rate QBER in the basis estimated prior to the protocol.
- 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 H} is the Hadamard gate. .
- is the probability that Sender (Receiver) prepares (measures) a qubit in the 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 X} basis.
- , Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \epsilon'_{\rm EC}} are the error probabilities of the error correction protocol.
- is the error probability of the privacy amplification protocol.
- is the error probability of the parameter estimation.
Properties
The protocol-
- is Information-theoretically secure
- requires synchronous network, authenticated public classical channel, secure from coherent attacks
- implements 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 (n,\epsilon_{\rm corr},\epsilon_{\rm sec},\ell)} -QKD, which means that it generates an -correct, 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 \epsilon_{\rm sec}} -secret key of 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 \ell} in rounds. The security parameters of this protocol are give by
and the amount of key that is generated is given by
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 -\log(\frac{8}{{\epsilon'}_{\rm EC}^2}+\frac{2}{2-\epsilon'_{\rm EC}})-\log (\frac{1}{\epsilon_{\rm EC}})- 2\log(\frac{1}{2\epsilon_{\rm PA}})}
where
and is the binary entropy function.
In the above equation for key length, the parameters 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 \epsilon_{\rm EC}} and are error probabilities of the classical error correction subroutine. At the end of the error correction step, if the protocol does not abort, then Sender and Receiver share equal strings of bits with probability at least . The 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 \epsilon'_{\rm EC}} is related with the completeness of the error correction subroutine, namely that for an honest implementation, the error correction protocol aborts with probability at most 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 \epsilon'_{\rm EC}+\epsilon_{\rm EC}} . The 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 \epsilon_{\rm PA}} is the error probability of the privacy amplification subroutine and is the error probability of the parameter estimation subroutine used to estimate . (See Quantum Key Distribution for the precise security definition)
Pseudo Code
- Input:
- Output:
Stage 1 Distribution and measurement
- For i=1,2,...,n
- Sender chooses random bits and such that
- Sender prepares and sends it to Receiver
- Receiver announces receiving a state
- Receiver chooses bit such that
- Receiver measures in basis with outcome
- At this stage Sender holds strings and Receiver , all of length
Stage 2 Sifting
- Alice and Bob publicly announce
- For i=1,2,....,n
- If
- append</math>(A_i)</math>
- append
- append
- append
- If
- Now Sender holds strings and Receiver , all of length
Stage 3 Parameter estimation
- For
- size = 0
- If{
- Sender and Receiver publicly announce
- Sender and Receiver compute , where is the Kronecker delta
- size += 1\;
- Both Sender and Receiver, each, compute
Stage 4 Error correction
- is an error correction subroutine determined by the previously estimated value of and with error parameters and
- Both Sender and Receiver run .
- Receiver obtains
Stage 5 Privacy amplification
- is a privacy amplification subroutine determined by the size , computed from equation for key length (see Properties), and with secrecy parameter
- Sender and Receiver run and obtain secret keys \;
Further Information
- BB(1984) introduces the BB84 protocol, as the name says, by Charles Bennett and Gilles Brassard.
- TL(2017) The derivation of the key length in Properties, combines the techniques developed in this article and minimum leakage error correcting codes.
- GL03 gives an extended analysis of the BB84 in the finite regime.
- Sifting: the BB84 protocol can also be described in a symmetric way. This means that the inputs and are chosen with the same probability. In that case only of the generated bits are discarded during the sifting process. Indeed, in the symmetric protocol, Alice and Bob measure in the same basis in about half of the rounds.
- LCA05 the asymmetric protocol was introduced to make this more efficient protocol presented in this article.
- A post-processing of the key using 2-way classical communication, denoted Advantage distillation, can increase the QBER tolarance up to (3).
- We remark that in Pseudo Code, the QBER in the basis is not estimated during the protocol. Instead Alice and Bob make use of a previous estimate for the value of and the error correction step, Step 4 in the pseudo-code, will make sure that this estimation is correct. Indeed, if the real QBER is higher than the estimated value , Pseudo Code will abort in the Step 4 with very high probability.
- The BB84 can be equivalently implemented by distributing EPR pairs and Alice and Bob making measurements in the and basis, however this required a entanglement distribution network stage.