Implementation of the B92 QKD protocol
The B92 protocol for quantum key distribution [see Phys.
Rev. Letter, 68,3121 1992] is implemented in QuCrypt
similarly to the way the BB84 protocol is implemented. In the following
we list all important steps and give some details of implementation.
We also show how Alice (the initiator) can configure the protocol settings
before the execution. An example of the output produced by the execution
of the B92 protocol can be found here. The B92
suffers more security weaknesses then the BB84 scheme. We don't have
any security analysis for this protocol.
The B92 QKD protocol:

(quantum transmission) The B92
quantum transmission is executed.

(good positions selection) Bob announces the positions
he could identify with certainty. Let
N be the number of
remaining bits. The key shared at this point is called the raw key
(note that it is not really shared since Alice's and Bob's version
are different).

(error estimation) Alice announces a subset of positions
of size K and the bit values for those positions in the raw
key. Bob also returns the bits he received in those positions. Both players
compute the observed errorrate e and accept the quantum
transmission if e <= e_{max}
as set initially by Alice. They finally remove the K bits
announced from the raw key . If e >e_{max}
then Alice and Bob abort.

(reconciliation) Alice and Bob perform an interactive
reconciliation protocol releasing an extra R parity bits
about the reconciled key which is the corrected version of the raw key
(see below). If the
resulting errorrate e_{real}
> e_{max} then Alice
and Bob abort.

(confirmation) Alice selects L random
subsets X_{1},...,X_{L }of
positions and announces X_{i }together with the parity
of all bits in X_{i} for 1<= i <= L.
Bob compares the parity bits announced by Alice to the one he gets
with his bits and tells Alice whether they are all the same. If some parity
bits do not match then Alice and Bob abort.

(privacy amplification) Alice announces to Bob the
description of a randomly selected hashing function f from
NK
bits to NKLRS
secret bits (see below). They
each applies f on the reconciled key in order to get the
final secretkey X_{f }in {0,1}^{NKLRS}.
Initial Configuration
Alice is responsible to setup the configuration for the protocol
execution. This can be done by settings the values in the configuration
panel. The panel looks as follow:
The length of the raw key here is different than
the value of N defined above. It is length of the quantum
transmission before the positions not detected with certainty have been
removed. This is the number of pulses received by Bob and measured in whatever
basis and leading to whatever result. If M is the value
selected (here in the example we have M=500), then the
value of N is approximatively M/4.
The porportion for sample is the number of random
positions among N that have been received by Bob and measured
in the right bases that are going to be sampled for errorrate estimation.
In the example above, 0.1N positions will be used in order
to compute the observed errorrate e.
The size of confirmation sample is the value for
L
as defined in the protocol description . In the example above, 10 random
subsets will be picked and their parity exchanged. The reconciled
key will be identical except with probability at most 2^{L}
whenever the confirmation phase succeeds.
The proportion for PA allows to set the value of
S
as described in the protocol description. In the example above, we
the S=0.05(NK) will be selected.
The last option allows for the transmission of an encrypted
short message after QKD has been executed with success. This is mainly
for demonstration purposes.
Good
Positions identification and Error Estimation
The identification of positions that have been detected reliably
by Bob and the errorestimation are implement in PlainB92
class. The result of this phase is the raw key.
Reconciliation
and Confirmation
Reconciliation has been implemented using protocol CASCADE.
It is a paritybased and interactive errorcorrection algorithm. Although
CASCADE requires a lot of interaction thus slowing
down the rate at which secretkey generation can be achieved, it allows
to save more bits of key after privacy amplification. If the quantum channel
is an expensive ressource then it is probably better to spend more time
during reconciliation in order to save more final bits. Moreover, the saving
of more bits also means that for a fixed errorrate, secure key distribution
can be achieved over longer distances. On the other hand, if for
some settings the rate at which the secretkey is generated is the main
concern, using a less interactive version of CASCADE
might be preferable (especially when the classical channel is slow like
the internet). We use the fully interactive version of CASCADE
in order to get R as close to Shannon's lower bound (NK)h(e)
as possible. Reconciliation is the most time consuming operation
in the classical phase. Under our experimental conditions, it requires
a time comparable to what is needed for raw key generation. Interaction
is very expensive on the internet. Here you can find more information
about CASCADE.
CASCADE is implemented in the Cascade
class.
Confirmation is implemented the obvious way and allows
to make sure that Alice and Bob are sharing identical keys (which
is not completely secret). In particular and for a given L,
the probability that Alice and Bob think they share identical keys while
in fact they don't is no more than 2^{L}.
Reconciliation and confirmation in the B92 scheme are
implemented in the
RecB92 class.
Privacy Amplification
Privacy amplification consists for Alice in choosing randomly
a hashing function f:{0,1}^{NK}
> {0,1}^{NKLRS} from some
class F. She then announces the description of f over
the public channel allowing Alice and Bob to compute the final key X_{f}=f(X_{A})=f(X_{B})
where X_{A} and
X_{B}are
the partially secret strings in {0,1}^{NK }obtained
after confirmation. In order for privacy amplification to produce a statiscally
secret X_{f},
the class F must be universal_{2}
(see BBR). Moreover, in order for privacy amplification to be efficient,
the description of f in F should be short.
We've implemented privacy amplification using an universal_{2}
class of hashing functions F introduced by
Krawczyk.
Any function f in F is described by a
Toeplitz matrix T_{s}
where s in {0,1}^{2N2KLRS
}is
randomly selected and sufficient for describing f.
As a result, the description of f requires the transmission
of only O(N) bits (oneway communication) and time in O(N^{2})
for evaluating it. This makes the contribution of privacy amplification
to the secretkey generation rate almost negligeable.
Privacy amplification in the B92 scheme is implemented
in the B92
class.