Re: Re: your ECP-QKD draft

Dear All,

James Carlson wrote:

>Mohamed Ali SFAXI writes:
>  
>
>>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/))
>>    
>>
>
>Yes, understood.
>
>However, none of the explanation you've offered actually addresses the
>questions I've asked.  Please examine this feature from your proposed
>draft:
>
>  
>
>>    To establish and configure the quantum key distribution between 
>>    the two nodes, it is necessary to exchange some data between 
>>    them. We propose a specific ECP packet format to carry QKD 
>>    parameters (Figure 2):
>>
>>
>>    0                   1                   2                   3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     Type      |    Length     |  Key-Length
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |     TTL     |T|    
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>    
>>
>[...]
>  
>
>>    Length field:
>>    The length is number of octets in the packet and it is more than 
>>    ?5? octets (1 octet for the type, 1 octet for the packet length, 
>>    2 octets for the key length and one octet for the TTL and the T 
>>    field).
>>    
>>
>
>This appears to describe a new option for ECP that exchanges keys
>between the peers, and does the exchange in the clear.
>  
>
Yes

>Why does it do that?  What does it have to do with quantum key
>exchange?
>  
>
In order to have a valid key, we need some negotiation before. The 
negotiation is done thanks to ECP. The two peers have to agree on the 
key length, TTL and perhaps additional option not described in our draft.
when these parameters are fixed, a QKD starts. This is done out of the 
PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to 
show that the network phase will start after the key is shared.
after that, the key is delivered to the network phase to encrypt data

>Moreover, the draft does not explain how the key to be used with the
>chosen algorithm is actually derived, nor what algorithms are
>possible, so there's essentially no hope of interoperability.  As IETF
>documents have the explicit goal of producing interoperable
>implementations, this draft falls short of what's needed.
>  
>
We didn't propose any encryption algorithm that could be used because 
all the encryption algorithms that are already recognized by PPP could 
be used. In fact, we have  introduced only a new way to obtain the 
encryption key. I think that our draft do not harm the interoperability.


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