[Pppext] Re: your ECP-QKD draft
Mohamed Ali SFAXI <MohamedAli.Sfaxi@unil.ch> Thu, 13 October 2005 12:10 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1uN-0003Bc-BD; Thu, 13 Oct 2005 08:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1o2-00010Z-6I for pppext@megatron.ietf.org; Thu, 13 Oct 2005 08:03:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13177 for <pppext@ietf.org>; Thu, 13 Oct 2005 08:03:24 -0400 (EDT)
Received: from uldns1.unil.ch ([130.223.8.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ1yW-0001D8-KA for pppext@ietf.org; Thu, 13 Oct 2005 08:14:21 -0400
Received: from hec170-187.unil.ch ([130.223.170.187]) by uldns1.unil.ch with esmtp (Exim 4.44) id 1EQ1nb-0004At-Rk; Thu, 13 Oct 2005 14:03:03 +0200
Message-ID: <434E4D01.5030400@unil.ch>
Date: Thu, 13 Oct 2005 14:03:13 +0200
From: Mohamed Ali SFAXI <MohamedAli.Sfaxi@unil.ch>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Carlson <james.d.carlson@sun.com>
References: <17229.15711.955152.614897@gargle.gargle.HOWL>
In-Reply-To: <17229.15711.955152.614897@gargle.gargle.HOWL>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2
X-Mailman-Approved-At: Thu, 13 Oct 2005 08:10:02 -0400
Cc: pppext@ietf.org, sgh@unil.ch
Subject: [Pppext] Re: your ECP-QKD draft
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0890758624=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org
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 pppext@ietf.org. 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 Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext
- Re: [Pppext] Re: your ECP-QKD draft Vernon Schryver
- [Pppext] Re: your ECP-QKD draft Mohamed Ali SFAXI
- Re: [Pppext] Re: your ECP-QKD draft James Carlson
- Re: [Pppext] Re: your ECP-QKD draft Vernon Schryver
- Re: [Pppext] Re: your ECP-QKD draft Mohamed Ali SFAXI
- Re: [Pppext] Re: your ECP-QKD draft Mohamed Ali SFAXI
- Re: [Pppext] Re: your ECP-QKD draft James Carlson
- Re: [Pppext] Re: your ECP-QKD draft James Carlson
- Re: [Pppext] Re: your ECP-QKD draft Mohamed Ali SFAXI
- Re: [Pppext] Re: your ECP-QKD draft Vernon Schryver
- Re: [Pppext] Re: your ECP-QKD draft Bill Manning
- Re: [Pppext] Re: your ECP-QKD draft Rod Van Meter
- Re: [Pppext] Re: your ECP-QKD draft James Carlson