Re: Re: your ECP-QKD draft

a couple of things here:


the I-D is in the DB at
https://datatracker.ietf.org/public/idindex.cgi? 
command=view_related_docs&id=13770
  but clicking on the "view document" link gets nothing!

and one of my quantum computing cohorts makes this comment:

 >Mr. Sfaxi either misunderstands or fails to explain one VERY important
 >point:  QKD REQUIRES an authenticated classical channel to operate
 >securely.  Such a channel involves either PKI or a pre-shared secret.
 >
 >See
 >http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix- 
what-shor.html
 >http://dabacon.org/pontiff/?p=1086
 >and especially
 >http://arxiv.org/abs/quant-ph/0406147
 >
 >As to id-quantique and MagiQ Technologies, they have been around for a
 >couple of years.  I don't know anyone who has actually purchased and
 >used their equipment.  If you know anyone who has, please ask them to
 >contact me; I would love to find out about their experiences!
 >
 >Feel free to forward this to the reflector, and include me on any
 >replies or further conversations, but I don't read pppext.
 >
 >               --Rod


On Oct 14, 2005, at 6:23, Mohamed Ali SFAXI wrote:

>  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.
>>
>
>> Why does it do that?  What does it have to do with quantum key
>> exchange?
>>
>
>  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.
>>
>
>
>
>  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

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