Re: Re: your ECP-QKD draft

> > 
> > More important, your document fails to specify how to exchange keys
> > using quantum crypography.  I suspect that there is more than one way,
> > and that some sort of negotiating might be useful.  That negotiating,
> > if needed, sounds like an appropriate subject of an RFC.  However,
> > your draft of an I-D does not in any way address such issues.
> >   
> The QKD negotiation depends mainly on the QKD protocols. We assume
> that the modems and the software in these modems are the only
> concerned by the negotiation. I completely agree with you to have a
> common negotiation way in QKD.

But there is a great deal more to negotiate about a QKD exchange than I
see specified in your document.

A quick glance at http://arxiv.org/abs/0503058/ shows at least the
following levels of the protocol that must be software-selected; I
believe the selection must be the same at both ends, therefore, they
seem like good candidates for a negotiation (and getting that
negotiation right so that a man in the middle can't "dumb down" the
protocol and create a vulnerability to exploit would be the fun and
tricky part):

* Authentication (BBN has implemented two methods)
* Privacy amplification (one method so far)
* entropy estimation (four methods) (this might be local info only, not
sure)
* error detection and correction (two methods)
* sifting (two methods)

That's just what BBN has implemented so far, and I know there are
further methods for various portions of the protocol.  There are dozens
-- maybe a hundred -- good papers on QKD, many of which propose some
slight variant to the protocol that enhances some characteristic that
the authors care about.  Many of those will ultimately fall by the
wayside (some will be *shoved* aside -- QKD researchers, like security
researchers everywhere, delight in attempting to prove each other
wrong), but some will ultimately be negotiable parameters.

> > This is all supposed to be about assigning an ECP type number to BB84.
> > I've been told by people actually working on quantum cryptography and
> > quantum computing that BB84 is an extremely unlikely choice.  Actually,
> > the words they used about this whole proposal were a lot stronger.

> >   
> 
> We propose the BB84 as it is the initial QKD protocol and the most
> famous. In addition, BB84 is still used by MagiQ and IdQuantique. 

Indeed, somewhat to my surprise, it does seem that both are still using
BB84.  Bennett92 requires the creation of only two polarized states,
compared to BB84's four, so it would seem that it should be easier to
implement in hardware, but I'm not building it, so what do I know?  Some
of the further, more modern variants I'm less familiar with.  BBN also
is using BB84 at the moment, but claims to be working on newer protocols
(B92? Lo-Chau?).  I'm not sure which, if either, is actually more
bandwidth- or photon-efficient.

This choice will be made by the modem hardware (actually, modem is a
misnomer, but we'll work with it), and will probably be as fundamentally
unchangeable as the wavelength (though even here I could be wrong, given
flexible enough hardware).  I know the modems have to be "trained up" to
match corresponding states, and I know that has to be repeated on a
regular basis because phases drift with the temperature of the fiber.  I
don't know if there is a need for a classical control protocol here, or
if it's all handled in-band (e.g., by simply selecting some of the bits
as state maintenance bits).

It should be obvious that I know quite a bit about QKD.  It should be
equally obvious that I know nowhere near enough to write an RFC about
how to control it and integrate it with either IPSEC or PPP.  If it were
me, I would leave this to the folks actually doing the work -- or,
perhaps, attempt to create an alliance with them to co-write it, if they
are able to contribute technically but lack either the time or
proficiency to generate the complete RFC by themselves.  RFCs should be
written by the people doing the work; even the proxy method I just
described is a poor substitute for it.

		--Rod



_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext