Re: [Cfrg] QKD is pointless

David McGrew <mcgrew@cisco.com> Fri, 10 January 2014 00:07 UTC

Return-Path: <mcgrew@cisco.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 1D4031AD7C0 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 16:07:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Level:
X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 BLoH7reEDLu6 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 16:07:40 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2201AD34C for <cfrg@irtf.org>; Thu, 9 Jan 2014 16:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6770; q=dns/txt; s=iport; t=1389312451; x=1390522051; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Un0oHn3GDzXm++ryo8UD5O5ffnySqLnuw6Lnjy8l4K4=; b=Bns5Oufd1uaowTnghvwxfNEnwx87Twrf813l/2ANCt7Se9+vgCkOVHYS 3h/uC0vNnW4Me8eR5R9xzEhiIAoKgPzYf3AcryixM5mRxwpc8wzEJzWIp +QwLa6uAoH+Zl8wm2aU/ohvUJQ5Gbe+6yjnwefaW7nJgVmKMcxo9oR7jH 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAOI4z1KrRDoG/2dsb2JhbABZgws4uheBEBZ0giUBAQEDATgzAwIIAQUHBAsRBAEBAQkWCAcJAwIBAgE0CQgGDQEFAgIFEodhBw7DNBeOGBUHAQEGSQcGhDEBA4UdhCaOVIEwgmSCMYtQg0segSwBCBc
X-IronPort-AV: E=Sophos;i="4.95,634,1384300800"; d="scan'208";a="102474691"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 10 Jan 2014 00:07:28 +0000
Received: from [10.0.2.15] (dhcp-10-155-84-23.cisco.com [10.155.84.23]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0A07RpP015795; Fri, 10 Jan 2014 00:07:27 GMT
Message-ID: <52CF3890.4010309@cisco.com>
Date: Thu, 09 Jan 2014 19:02:24 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: "Igoe, Kevin M." <kmigoe@nsa.gov>
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com> <52CD314B.2000604@cisco.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A1129@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABA9A1129@MSMR-GH1-UEA03.corp.nsa.gov>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Sean Turner <TurnerS@ieca.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] QKD is pointless
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: Fri, 10 Jan 2014 00:07:43 -0000

Hi Kevin,

On 01/08/2014 01:06 PM, Igoe, Kevin M. wrote:
> We really need to make sure at least some of the mailing list
> has some expertise in a given area before we commit ourselves
> to working in that area,

I completely agree, the RG needs to be cautious about making sure that 
it does not overcommit to work.

> and anything with "quantum" in the name
> requires expertise I expect very few (if any) of the maining list
> possess.  I suggest before committing to a topic we poll the
> mailing list to see who has both expertise on a given topic and
> an employer who is willing to donate the time and resources
> needed to follow through.

I think I was not clear in what I meant, please see inline below:

>
>> -----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.

Instead of the last sentence, what I should have said is: if there is a 
need to better explain and/or defend the points outlined above, I 
personally would be willing to spend the time to write them up.

Speaking as an individual here: I don't think QKD is something worth the 
RG's time.   Post-quantum crypto, on the other hand, is something I 
would be very glad to see work on.

David

>>
>> David
>>
>>> spt
> .
>