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

David McGrew <mcgrew@cisco.com> Wed, 08 January 2014 11: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 63FFD1AE2A1 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:07:03 -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 6z_-zLem1cq3 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 03:07:01 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0E1AE28F for <cfrg@irtf.org>; Wed, 8 Jan 2014 03:07:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5139; q=dns/txt; s=iport; t=1389179212; x=1390388812; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gU6SE+E1tHKBiegc2vY4oYsv6o1ncKnqJK4mDChyOOg=; b=OeS/hG3jc2ygImqpXp84YFxw9k2HvCxEmxUScixiH8lDoUCLYJUP0vM6 amR8yFaZERz9rCI5SP6sJN2eNlwD+MxTGUMz031HScBYOUinkI3BjE2H3 AdhlcjuzFzaCdZOfnHUY6bLnZXN6nOwT2QzKW8t9Yv/OAre8iu98vZyBR A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAPYvzVKrRDoI/2dsb2JhbABZgws4ukaBFBZ0giUBAQEDATIBBTgIARAjCRYPCQMCAQIBRQYNAQcCBRKHYQcOxFoXjhgVBwEBBkkHhDcBA4UdhCaOVIEwgmSCMYtQg0segSwBCBc
X-IronPort-AV: E=Sophos;i="4.95,623,1384300800"; d="scan'208";a="102384403"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 Jan 2014 11:06:52 +0000
Received: from [10.0.2.15] ([10.21.70.52]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s08B6pKQ022294; Wed, 8 Jan 2014 11:06:51 GMT
Message-ID: <52CD314B.2000604@cisco.com>
Date: Wed, 08 Jan 2014 06:06:51 -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: Sean Turner <TurnerS@ieca.com>
References: <52C755AA.70200@cisco.com> <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com>
In-Reply-To: <33E0BF53-A331-4646-B080-FD4F6E13916E@ieca.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: cfrg@irtf.org
Subject: [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: Wed, 08 Jan 2014 11:07:03 -0000

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