Re: your ECP-QKD draft

Dear James Carlson,


Thank you for your comments here is our answer :

 

How:

 

To exchange the quantum key , both nodes must have some special features 
(quantum devices) or simply a quantum modem (these modems like are 
already sold by some companies such as IdQuantique (www.idquantique.com) 
and MagiQ (http://www.magiqtech.com/))

 

Here are some requirements to perform a quantum key distribution:

 

a- An optical channel: the optical channel is the physical link between 
two adjacent nodes. Nowadays, there are two means able to carry a 
quantum cryptography transmission: the optical fibber or the free space 
(the air) [6]. As the quantum cryptography uses photons to encode the 
information no other channel could be used up to now. However, as the 
quantum physics are experimenting the use of atoms and electrons as a 
quantum particle [7, 5] maybe other kind of channel could be used in the 
future.

 

b- A Q3P modem: this modem has to polarize, send and detect photons; it 
has to include a photon detector and a laser with a single photon 
emitter and photon polariser. The source and the detector are widely 
commercialised and many techniques are employed1. However, these devices 
are used to exchange the quantum key but could also used to send and 
receive simple data depending on how encoding the information. The modem 
in this case is a simple optical fiber modem.

 

c- QKD protocol: in order to establish an unconditional secure key, a 
quantum key distribution protocol is needed. This protocol must be 
implemented in the Q3P modem. The protocol will deliver a secure key 
after distilling the key and error correction [3]. The key is stored in 
a flash buffer memory and used when enciphering the data. The QKD 
protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic 
protocols widely used. These protocols are securely proven and largely 
experimented [4].

 

      

 

Why:

 

All encryption algorithms used in PPP assume that there is an already 
shared secret between the two nodes as cited in [RFC2419]: "The means by 
which the secret becomes known to both communicating elements is beyond 
the scope of this document; usually some form of manual configuration is 
involved". We don't know how this key is generated, shared nor installed 
in the PPP devices.

Using the Q3P (and especially the QKD), we solve all the secure key 
exchange problems. In fact, we could exchange an unconditional secure 
key, on-demand and dynamically.

 

 

 

What might be done by this key :

- can be used for instance in DESE  [RFC2420] as the "initial nonce".

- Can also be used in other encryption algorithms such as "One Time Pad" 
function which need a new key for each message

 

 

 

 

 

References:

 

1. Bennet, C; Brassard, G (1984). IEEE International Conference on 
Computers, Systems, and Signal Processing. IEEE Press, LOS ALAMITOS

 

2. Bennet, (1992). C Quantum Cryptography: Uncertainty in the Service of 
Privacy. Science 257.

 

3. Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). "Quantum 
Cryptography". Reviews of Modern Physics 74

 

4 Guenther, C (2003) "The Relevance of Quantum Cryptography in Modern 
Cryptographic Systems". GSEC Partical Requirements (v1.4b). 
http://www.giac.org/practical/GSEC/Christoph Guenther GSEC.pdf

 

 5. Knight, P (2005). "Manipulating cold atoms for quantum information 
processing". QUPON conference Vienna 2005.

 

6. R.Hughes,J.Nordholt,D.Derkacs,C.Peterson, (2002). "Practical 
free-space quantum key distribution over 10km in daylight and at night". 
New journal of physics 4 (2002)43.1-43.14.

 

7. Tonomura, A (2005). "Quantum phenomena observed using electrons". 
QUPON conference Vienna 2005.



*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

 



James Carlson wrote:

>This is currently being discussed on [email protected].  I encourage you
>to participate in the discussion.
>
>The current concern is that the draft appears to have an explicit key
>exchange (as part of the negotiation), but that the draft doesn't
>explain how or why this key exchange exists, or what might be done
>with those keys.  (Clearly, they cannot be used for ECP, as they've
>already been exposed to attackers by the negotiation itself.)
>
>Because of the lack of clarity in the specification, it seems likely
>that the consensus will be to deny the request for a new ECP code
>point, unless you can successfully argue your case.
>
>  
>

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