Re: Re: your ECP-QKD draft

Dear All,


Vernon Schryver wrote:

>>From: Mohamed Ali SFAXI <[email protected]>
>>To: James Carlson <[email protected]>
>>Cc: [email protected], [email protected]
>>    
>>
>
>  
>
>>Thank you for your comments here is our answer :
>>    
>>
>
>Your answer is not responsive.
>
>Perhaps the best way to answer the objections to the I-D and the
>proposed IANA registry would be for you to build a complete prototype
>implementation of the idea or at least a design complete in all
>aspects.  Given your claim that quantum cryptography is a settled
>technology (never mind http://www.idquantique.com/news/files/june-05.pdf ),
>it should be easy to make a complete design including writing software.
>You could base such an effort on one of the open-source implementations
>of PPP with encryption and add whatever is needed to work with your
>quantum encryption hardware.  You would not need to buy quantum
>cryptography hardware but could write code to specifictions obtained
>from id Quantique or MagiQ.
>
>
>  
>

We are already in contact with Idquantique and maybe we will propose 
something togother.

>  
>
>>To exchange the quantum key , both nodes must have some special features=20
>>(quantum devices) or simply a quantum modem (these modems like are=20
>>already sold by some companies such as IdQuantique (www.idquantique.com)=20
>>and MagiQ (http://www.magiqtech.com/))
>>    
>>
>
>As far as PPP is concerned, exactly the same is true of any use of 
>PPP encryption.  In general one does not change PPP when one uses
>new kinds of modems.
>
>
>  
>

You are right. However, the question was how to exchange the key so I 
answered to that question.

>>Here are some requirements to perform a quantum key distribution:
>>
>>a- An optical channel: the optical channel is the physical link between=20
>>two adjacent nodes. Nowadays, there are two means able to carry a=20
>>quantum cryptography transmission: the optical fibber or the free space=20
>>(the air) [6]. As the quantum cryptography uses photons to encode the=20
>>information no other channel could be used up to now. However, as the=20
>>quantum physics are experimenting the use of atoms and electrons as a=20
>>quantum particle [7, 5] maybe other kind of channel could be used in the=20
>>future.
>>    
>>
>
>That fact does not affect PPP, and does not answer the questions
>that have been raised about your I-D.
>
>  
>

Same thing

>>b- A Q3P modem: this modem has to polarize, send and detect photons; it=20
>>has to include a photon detector and a laser with a single photon=20
>>emitter and photon polariser. The source and the detector are widely=20
>>commercialised and many techniques are employed1. However, these devices=20
>>are used to exchange the quantum key but could also used to send and=20
>>receive simple data depending on how encoding the information. The modem=20
>>in this case is a simple optical fiber modem.
>>    
>>
>
>That also does not affect PPP, and does not answer the questions raised
>about your I-D.
>
>  
>

Same thing

>>c- QKD protocol: in order to establish an unconditional secure key, a=20
>>quantum key distribution protocol is needed. This protocol must be=20
>>implemented in the Q3P modem. The protocol will deliver a secure key=20
>>after distilling the key and error correction [3]. The key is stored in=20
>>a flash buffer memory and used when enciphering the data. The QKD=20
>>protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=20
>>protocols widely used. These protocols are securely proven and largely=20
>>experimented [4].
>>    
>>
>
>That also has nothing to do with PPP.  Never mind that I disagree with
>the claim that anything about quantum cryptography is settled technology.
>Except that the encryption key is negoiated with quantum cryptography,
>that description fits existing PPP encryption implementations.
>
>In fact, your description fits existing PPP implementations better
>than a system involving quantum cryptography, because I doubt that one
>would want to store keys negotiated with quantum cryptogrpah in a flash
>buffer memory.
>
>
>  
>

>>Why:
>>
>>All encryption algorithms used in PPP assume that there is an already=20
>>shared secret between the two nodes as cited in [RFC2419]: "The means by=20
>>which the secret becomes known to both communicating elements is beyond=20
>>the scope of this document; usually some form of manual configuration is=20
>>involved". We don't know how this key is generated, shared nor installed=20
>>in the PPP devices.
>>
>>Using the Q3P (and especially the QKD), we solve all the secure key=20
>>exchange problems. In fact, we could exchange an unconditional secure=20
>>key, on-demand and dynamically.
>>    
>>
>
>Yes, but that has nothing to do with PPP itself.
>
>well, I'm not quite right.  Anyone who understands PPP sees an opportunity
>to write a real I-D saying when to use quantum cryptography to negoiate
>a new key PPP encryption key based on certain PPP state changes.  That
>would not involve a change to PPP beyond a pause for obtaining new
>random numbers (keys) and negotiating exchanging them over the (presumably
>relatively slow) quantum cryptography channel before continuing PPP
>as usual.
>
>
>  
>
>>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"=20
>>function which need a new key for each message
>>    
>>
>
>The only positive way I understand that statement is as proposing to
>use quantum cryptography not exchange keys before IPCP starts but to
>carry all PPP bits.  As such it still has nothing to do with PPP,
>because you are proposing a new channel above which would be PPP. 
>In other words, do MagiQ (http://www.magiqtech.com/) and id Quantique
>(http://www.idquantique.com/) agree with your claim that PPP must be
>changed to use their modems?
>
>PPP often does not change to use new kinds of conventional modems.
>
>
>Vernon Schryver    [email protected]
>  
>

Our idea was to create some kind of ECP negotiation to fix the key 
exchange parameters and then start the QKD to share a secret key, So it 
is normal that the existing PPP implementations fits well. The only 
difference is that to start the network phase using an encryption 
algorithm we can choose to use the QKD to share a secret key or to 
assume that the key is already shared (i..e what is done now in PPP).


Best regards,


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

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

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