Error message
- Deprecated function: TYPO3\PharStreamWrapper\Manager::initialize(): Implicitly marking parameter $resolver as nullable is deprecated, the explicit nullable type must be used instead in include_once() (line 19 of includes/file.phar.inc).
- Deprecated function: TYPO3\PharStreamWrapper\Manager::initialize(): Implicitly marking parameter $collection as nullable is deprecated, the explicit nullable type must be used instead in include_once() (line 19 of includes/file.phar.inc).
- Deprecated function: TYPO3\PharStreamWrapper\Manager::__construct(): Implicitly marking parameter $resolver as nullable is deprecated, the explicit nullable type must be used instead in include_once() (line 19 of includes/file.phar.inc).
- Deprecated function: TYPO3\PharStreamWrapper\Manager::__construct(): Implicitly marking parameter $collection as nullable is deprecated, the explicit nullable type must be used instead in include_once() (line 19 of includes/file.phar.inc).
- Deprecated function: UpdateQuery::expression(): Implicitly marking parameter $arguments as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: MergeQuery::expression(): Implicitly marking parameter $arguments as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQueryInterface::getArguments(): Implicitly marking parameter $queryPlaceholder as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQueryInterface::preExecute(): Implicitly marking parameter $query as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQueryExtender::getArguments(): Implicitly marking parameter $queryPlaceholder as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQueryExtender::preExecute(): Implicitly marking parameter $query as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQuery::getArguments(): Implicitly marking parameter $queryPlaceholder as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
- Deprecated function: SelectQuery::preExecute(): Implicitly marking parameter $query as nullable is deprecated, the explicit nullable type must be used instead in require_once() (line 1884 of includes/database/database.inc).
#1
Wed, 26/11/2008 - 05:35
Actually, the real security
Actually, the real security of BB84 lies in a bit of random guesswork combined with error correction. It is assumed that Eve does gain some information but through error correction it can be shown that Alice and Bob can correct down to the point that Eve has zero usable information. An awesome reference on this, particularly from a pedagogical point of view, is the book Protecting Information: From Classical Error Correction to Quantum Cryptography by Susan Loepp and Bill Wootters and published by CUP.
Why this doesn't work
I guess you already had your lecture by now, but here is the reason why the CNOT does not work:
A CNOT doesn't work exactly as you assume in your post. You write "use the bits sent to Bob as control in a CNOT, keeping the second bits, and passing on the original qubits unchanged". The control qubit is a CNOT is only unchanged if it is diagonal in the computational basis. For example if you start out with a state |+>|-> (where the first is the control, the second is a target, |+> = (|0>+|1>)/normalization and |-> = (|0>-|1>)/normalization), applying a CNOT will change the state to |->|->, i.e. the control will change but the target will be left unchanged.
In the attack with the CNOT you need to specify what state the target qubit is in initially. I assume this it is in |0> (which is probably what you meant). If you try the attack, you will be able to read the bits without introducing errors when the signal states are |0> or |1>. However, if the signal state is |+>, you will get the entangled state |00>+|11> (I neglect normalization due to formatting). If Bob measures this bit in the +/- basis he should get the outcome |+> with probability 1 if there were no eavesdropping. However, the reduced state is now |0><0| + |1><1| which is the same as |+><+| + |-><-|. The probability of measuring |-> is therefore 0.5. Thus, there will be 50 % error rate in the +/- basis and 0 % error rate in the computational basis, which is the same as what you get if you simply measure in the 0/1 basis and resend to Bob what you measured.
You are right when you say that Eve has exactly what Bob has. They both have the bit Alice sent when she used the 0/1 basis, but they both have complete garbage when Alice sends using the +/- basis. Bob knows that when there are so many errors there is no way to make a secret key.
There are ways for Eve to get exactly what Bob has without introducing so many errors (we say that Alice and Bob's state has a [[symmetric extension]]). It is possible for Eve to introduce an average error rate of only 14.6% (as opposed to 25% in the above attack) and still have the same information as Bob. In this case it is possible for Alice and Bob to distill some key anyway by a techinque called [[advantage distillation]].