Re: [Cfrg] QKD is pointless (was: Re: considering new topics for CFRG)

Paul Lambert <paul@marvell.com> Thu, 09 January 2014 01:56 UTC

Return-Path: <paul@marvell.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B031ADFB0 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2cw7jy3vp6Q for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:56:11 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA851ADFBF for <cfrg@irtf.org>; Wed, 8 Jan 2014 17:56:11 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s091txUL024077; Wed, 8 Jan 2014 17:55:59 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1h919rawu4-21 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 08 Jan 2014 17:55:59 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 8 Jan 2014 17:55:56 -0800
From: Paul Lambert <paul@marvell.com>
To: "Igoe, Kevin M." <kmigoe@nsa.gov>, "'David McGrew'" <mcgrew@cisco.com>, Sean Turner <TurnerS@ieca.com>
Date: Wed, 8 Jan 2014 17:55:55 -0800
Thread-Topic: [Cfrg] QKD is pointless (was: Re: considering new topics for CFRG)
Thread-Index: AQHPDGG93i3ZBM+NS0KqToyzCB9/tpp7IGAQgACBIAA=
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7053@SC-VEXCH2.marvell.com>
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com> <52CD314B.2000604@cisco.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A1154@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABA9A1154@MSMR-GH1-UEA03.corp.nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-09_01:2014-01-07, 2014-01-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080180
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] QKD is pointless (was: Re: considering new topics for CFRG)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:56:13 -0000

> -----Original Message-----
> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Igoe, Kevin M.
> Sent: Wednesday, January 08, 2014 10:15 AM
> To: 'David McGrew'; Sean Turner
> Cc: cfrg@irtf.org
> Subject: Re: [Cfrg] QKD is pointless (was: Re: considering new topics
> for CFRG)
> 
> I'd like to see the CFRG investigate how far the DANE paradigm can be
> pushed w/o bringing the system to a screeching halt.
> For example, there is a group an NIST looking at the possibility of
> leveraging DANE for use with e-mail.  Who else is out there hoping to
> piggy bank on DANE?  Can DANE be the new PKI?  
No. 

Nice hack, but lacking adequate semantics and constraint based
architecture to extend well beyond DNS based naming (email could work).

>If not, what features
> does it lack & can it be "patched"?
Anything could be patched ... but the core hierarchy structure
of DNS would be maintained and would always be of that flavor 
of that solution space. 

I'd like to see something that would work for mobile phones without
central servers ...

Paul

> 
> 
> > -----Original Message-----
> > From: David McGrew [mailto:mcgrew@cisco.com]
> > Sent: Wednesday, January 08, 2014 6:07 AM
> > To: Sean Turner
> > Cc: Igoe, Kevin M.; cfrg@irtf.org
> > Subject: QKD is pointless (was: Re: considering new topics for CFRG)
> >
> > Hi Sean,
> >
> > On 01/08/2014 12:26 AM, Sean Turner wrote:
> > > My list is kind of short:
> >
> > thanks for sharing your top of mind list, it will help us to
> prioritize
> > work.
> >
> > >
> > > 0) Could the CFRG get behind these recommendations for RSA-OAEP/PSS
> > or not:
> > > http://www.ietf.org/mail-archive/web/saag/current/msg04481.html
> > > http://www.ietf.org/mail-archive/web/saag/current/msg04482.html
> > >
> > > If so, let's do a draft!
> > >
> > > 1) Assuming RSA goes kaput, it seems like we're moving towards EC
> (am
> > I wrong here) then are these EC-based documents worth saying more
> about
> > (e.g., in the next version of the protocol use this or run away in
> > fear):
> > > https://datatracker.ietf.org/doc/rfc6979/
> > > https://datatracker.ietf.org/doc/draft-peck-ecdhpop/
> > > https://datatracker.ietf.org/doc/draft-jivsov-ecc-compact/
> > >
> > > 2) Is QKD something we need to start considering:
> > > http://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-
> 00.txt
> > > http://tools.ietf.org/id/draft-ghernaouti-sfaxi-ppp-qkd-00.txt
> >
> > #0 and #1 are well worth discussion.   For now, I will only comment
> on
> > #2.
> >
> > Quantum Key Distribution does not provide a solution to any problem
> > that we have at hand, and is not worthy of serious consideration for
> > extensive use in the Internet.
> >
> > The one benefit of QKD is that it does not rely on any computational
> > assumptions for security.   However, it relies on physical
> assumptions
> > for its security; that is, it can be attacked at the physical layer.
> > This is a terrible tradeoff, since physical attacks are possible at
> any
> > point between the encrypter and decrypter.   In addition, QKD
> requires
> > large amounts of raw entropy, and entropy generation is a harder
> > problem
> > in the real world than pseudorandomnes.   (In other words: a QKD
> system
> > could use AES-CTR to generate the large amounts of unpredictable
> > elements that it needs, but if we trust AES-CTR, why not just use
> that
> > algorithm directly to encrypt traffic?)
> >
> > QKD relies on point-to-point secret keys, and it is inherently and
> very
> > severely limited in what data rates and ranges that it can support.
> > The claimed speed record the last time that I checked was one megabit
> > per second at 20 KM range.   Using that technology, we need 10,000
> > repeaters to get global scale communication.   This would require the
> > pre-placement to 9,999 shared secrets between pairs of repeaters
> along
> > the communication path, and it would require that infrastructure to
> be
> > trusted.  There are theoretical designs for repeaters that would not
> > need to be trusted,
> >
> > The idea of "hybrid QKD", in which QKD is used to distribute keys for
> a
> > conventional symmetric cryptosystem like AES, is a seriously bad
> idea.
> > It suffers from the physical layer vulnerabilities of QKD as well as
> > whatever vulnerabilities the symmetric cryptosystem has.   It is
> *more*
> > vulnerable than a conventional symmetric system that uses the same
> > cipher for both traffic encryption and key distribution.
> >
> > QKD relies on the point to point transmission of individual photons,
> > and thus is inherently incompatible with wireless technologies such
> as
> > 4G
> > and 802.11.   The photons used in WiFi have 100,000 times less energy
> > than those used in the fibre optic links of QKD, and WiFi is not
> > geometrically point to point.   So even if QKD didn't suffer from the
> > problems described above, it would not be able to help the > 6
> billion
> > cellular wireless subscribers, or the vast number of WiFi users.
> >
> > QKD is inherently unsuited for all of the important trends in
> > information technology, including the "bring your own device" trend,
> > Could, virtualization, and collaboration.
> >
> > I gave an invited talk at the 2012 HP Information Security Colloquium
> > Royal Holloway with the title "The Vernam cipher is better than
> quantum
> > key distribution", which presented an analysis that backs up the
> claim
> > in the title.   The important observation here is that the classical
> > Vernam cipher, in which a long one-time pad is copied onto a portable
> > storage medium then used for information-theoretically secure
> > communication, is quantifiably better than QKD.   Vernam does not
> have
> > any physical-layer vulnerabilities, it does not have any range
> > limitations, and it can be used over wireless.   Its data rate will
> > depend on how frequently new pad material can be transported by a
> > trusted physical courier, but given the low data rates of QKD, a
> > courier
> > need not travel that often to match its data rate.   The important
> > inference is: if we were actually concerned about the possibility
> that
> > all symmetric ciphers could be vulnerable to cryptanalysis, then we
> > would be pursuing Vernam-type information theoretic secure systems,
> and
> > not QKD.   The reality is that there is no such concern, and interest
> > in
> > QKD is driven by its novelty, and not by any logical consideration of
> > what would be useful in information security.
> >
> > My talk isn't online (just mentioned but not archived
> > http://bristolcrypto.blogspot.com/2012_12_01_archive.html)   If we
> need
> > to get these points understood more widely, we could publish
> something
> > on it.
> >
> > David
> >
> > >
> > > spt
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg