4
$\begingroup$

I would like to expand upon this question: What is the probability of detecting Eve's tampering, in BB84?

Let's say that when the receiver (colloquially referred to as Bob) receives a qubit and measures it in the correct basis, the receiver still has a small percent chance of getting an incorrect measurement of the qubit due to noise. How does the protocol 'make room' for this error by accurately determining when the noise is a result of error, or a result of an eavesdropper?

$\endgroup$
2
  • $\begingroup$ This paper might be useful $\endgroup$
    – epelaaez
    Jul 3 at 21:00
  • 2
    $\begingroup$ You just attribute all noise as eavesdropping. $\endgroup$
    – Rammus
    Jul 3 at 21:00
4
$\begingroup$

The standard noisy approach is not to try to determine the presence of an eavesdropper as such, but to create a final key where, even if there is an eavesdropper, you can still be confident that the eavesdropper has negligible information about the key. So you aren't trying to distinguish between noise and eavesdropping, but pessimistically assuming that all noise may be due to eavesdropping, and obtaining a key that is still private, even given this (or deciding that the noise level is too high for this to be possible).

This is done through privacy amplification - details of specific protocols (like Cascade) are covered in links others have posted, but essentially these are classical hashing protocols: classically, if you have a sequence of bits the eavesdropper has some partial information about, you can hash those down to a shorter sequence that the eavesdropper provably has negligible information about.

Proving the security of this approach for BB84 (including how much key, if any, can be obtained given a certain noise level) is more complicated, since the eavesdropper isn't limited to just knowing some fraction of the classical bits, they can do quantum attacks like entangling their own qubits with the ones in transmission. The Shor-Preskill proof of BB84's security (using some earlier work by Lo and Chau) works by showing that the protocol (with hashing) is equivalent to distillation of EPR entangled states from noisy entangled pairs, with EPR pairs being inherently uncorrelated (in a quantum or classical sense) with an eavesdropper.

$\endgroup$
2
$\begingroup$

If there is an evasdroping, an error rate is higher than some long-term average of a quantum communication channel used for a quantum key distribution. So, when the error rate is high, the key is deleted and new one is distribuited again until noise level is at acceptable level.

A natural noise can be reduced with classical error correction, something like self-reparing codes.

See this thread for more information.

$\endgroup$
2
  • $\begingroup$ "when the error rate is high, the key is deleted and new one is distributed again until noise level is at acceptable level." - i.e. until the attacker gives up, or happens to measure most of the key bits in the same bases as Bob??? (hopefully this takes longer than a universe-lifetime) $\endgroup$
    – user253751
    Jul 4 at 9:21
  • $\begingroup$ @user253751: Good point, but I meant that in some cases a natural cause can lead to threshold noise exceeding. I would expect that when such event occurs few times in row, it would be good indication of evasdroping , the key distribution is interrupted and the chanel is no longer considered to be secured. $\endgroup$ Jul 4 at 16:29
0
$\begingroup$

I know that noise is a big challenge for running this protocol because it is hard to understand whether the error is produced by noise or eavesdropper. To make the success rate higher you assume that the noise is also caused due to eavesdropping. As you know this protocol heavily relies on probability calculations. So, while calculating the probability for eavesdropping, the noise is assumed to be included in it. The probability we achieve is enough to give information about the eavesdropper.

But, yeah if noise was removed we could get the exact probability values for eavesdropping.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.