[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
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Trevor Perrin
- [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG David Wagner
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Henrick Hellström
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG William Whyte
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Watson Ladd
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Adam Back
- [Cfrg] QKD is pointless (was: Re: considering new… David McGrew
- Re: [Cfrg] considering new topics for CFRG Stephen Farrell
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paterson, Kenny
- Re: [Cfrg] QKD is pointless (was: Re: considering… Sean Turner
- Re: [Cfrg] considering new topics for CFRG Sean Turner
- Re: [Cfrg] considering new topics for CFRG Max Pritikin (pritikin)
- Re: [Cfrg] considering new topics for CFRG Dan Brown
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless (was: Re: considering… Watson Ladd
- [Cfrg] DANE in the IETF (was: Re: considering new… Paul Hoffman
- [Cfrg] One Key -> RE: considering new topics for … Paul Lambert
- Re: [Cfrg] QKD is pointless (was: Re: considering… Paul Lambert
- [Cfrg] ReL DANE in the IETF (was: Re: considering… Paul Hoffman
- Re: [Cfrg] QKD is pointless David McGrew
- Re: [Cfrg] QKD is pointless Hilarie Orman
- [Cfrg] likelihood that someone has a quantum comp… David McGrew
- Re: [Cfrg] considering new topics for CFRG dan
- Re: [Cfrg] likelihood that someone has a quantum … David Jacobson
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … Watson Ladd
- Re: [Cfrg] likelihood that someone has a quantum … Yoav Nir
- Re: [Cfrg] likelihood that someone has a quantum … Stephen Farrell
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] likelihood that someone has a quantum … Igoe, Kevin M.
- Re: [Cfrg] QKD is pointless David Wagner
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … William Whyte
- Re: [Cfrg] likelihood that someone has a quantum … David McGrew
- Re: [Cfrg] likelihood that someone has a quantum … arne renkema-padmos
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG Igoe, Kevin M.
- Re: [Cfrg] considering new topics for CFRG Paul Lambert
- Re: [Cfrg] considering new topics for CFRG David McGrew
- [Cfrg] 'key centric' architecture (was: Re: consi… Rene Struik
- Re: [Cfrg] 'key centric' architecture (was: Re: c… Richard Barnes
- Re: [Cfrg] considering new topics for CFRG David McGrew