[Qirg] Re: questions about QKD

Rod Van Meter <rdv@sfc.wide.ad.jp> Tue, 04 June 2024 07:59 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901BC1E0D8F for <qirg@ietfa.amsl.com>; Tue, 4 Jun 2024 00:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.996
X-Spam-Level:
X-Spam-Status: No, score=-6.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sfc.wide.ad.jp
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o66DykUZr3TI for <qirg@ietfa.amsl.com>; Tue, 4 Jun 2024 00:59:10 -0700 (PDT)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D44AC1DFD50 for <qirg@irtf.org>; Tue, 4 Jun 2024 00:59:09 -0700 (PDT)
Received: from [IPV6:2400:2411:5002:6100:759a:d32b:4fd0:d142] (unknown [IPv6:2400:2411:5002:6100:759a:d32b:4fd0:d142]) (Authenticated sender: rdv) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 042588D54; Tue, 4 Jun 2024 16:59:06 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1717487946; bh=fXMFpfREcLJjJ0+62gI6EpgdrPFdrkzQ+FGV3pZnjcE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=BNs71Tps7zfysz/kkvuCebxO37VgrcX/4elfM9PoVHeQjxs+67KCtDbLohlDtbHvq G0To41llEzfUKT7hH/UhXMOauQ+tiJ4Re4A/hs7IbvR5V6dxgb2KL/dGlk5uyQY3Mn uU/TDB+SGUlGk/TAC1rXrwh2iHqkl1cqbfP752JhQwf/8Y0N9ZiXs8XE6OvPXbOzQe FlkWSC+qRa2DLjw/7x2z/M53MHhp9y15+Dt4FfhlNGiFhlJFT+qMbEWnWqTa3WQ8oo zOb/SO6InAqgmpCZVToZ/Ib839mAJk4rj2PKnYxRuHa4UHUbj/N8Y3V3KaDnyhBh/x 3JwWX7DR+VWDg==
Content-Type: multipart/alternative; boundary="------------q4meiwQfacT15Az7THBl8t3E"
Message-ID: <b856e6c3-709b-4eb5-8de6-1cff419a74e2@sfc.wide.ad.jp>
Date: Tue, 04 Jun 2024 16:59:05 +0900
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "qirg@irtf.org" <qirg@irtf.org>
References: <6fb0218c-1ce0-4fb8-a0ee-14347c357f29@sfc.wide.ad.jp> <GVXPR07MB96788AB065A0C97E6A976E7589F82@GVXPR07MB9678.eurprd07.prod.outlook.com>
Content-Language: en-US
From: Rod Van Meter <rdv@sfc.wide.ad.jp>
In-Reply-To: <GVXPR07MB96788AB065A0C97E6A976E7589F82@GVXPR07MB9678.eurprd07.prod.outlook.com>
Message-ID-Hash: CDDD62XPS2DXAQA3LKAESGXQSSICV6HG
X-Message-ID-Hash: CDDD62XPS2DXAQA3LKAESGXQSSICV6HG
X-MailFrom: rdv@sfc.wide.ad.jp
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-qirg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Qirg] Re: questions about QKD
List-Id: Quantum Internet RG <qirg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/13BuYujTgXnbgSeYXrZsckCVWyM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Owner: <mailto:qirg-owner@irtf.org>
List-Post: <mailto:qirg@irtf.org>
List-Subscribe: <mailto:qirg-join@irtf.org>
List-Unsubscribe: <mailto:qirg-leave@irtf.org>

On 2024/06/04 15:47, John Mattsson wrote:
>
>
> I think this is a very good summary. I think wide-area, multipurpose, 
> generally entangled quantum networks will be useful to connect quantum 
> computers and quantum sensors.
>
We absolutely, unequivocally have to have networking at the data center 
level in order the scale quantum computers, so agreed.
>
> Except some very niche military use cases where QKD could serve as a 
> defense-in-depth for ML-KEM, Classic McEliece, or FrodoKEM, it is hard 
> to see practical use for QKD even if the problems you list are solved.
>
I'm old enough to have been wrong about potential uses for technologies, 
so I'm a little more cautious about it, but by and large I agree; use 
cases for QKD are likely pretty narrowly defined.

> As a person how studied physics and then switched to computer science, 
> I am very disappointed in a lot of quantum people making public 
> statements about QKD as practical security.
>
I think rather than deliberately disingenuous statements the problem is 
that the QKD community has too few serious security people (like you). I 
will say (just among us...er, well, this will go in the list archives 
for posterity, I suppose...) I have encountered quite a few physicists 
in the last twenty years who are, shall we say, not fully acquainted 
with the breadth and depth of computer science and computer engineering. 
They are EXTREMELY good at what they do, I just wish they paid a little 
more attention to what WE do!

The real forehead-slapper is when someone hacks a given QKD system and 
the response is, "Oh, well, that's just an implementation problem, it's 
still theoretically secure," as if "theoretically secure" or "it would 
have been secure if you had implemented it right" systems aren't one of 
our biggest source of headaches.

> Relying on current QKD systems would be very dangerous security wise.
>
Despite what I just said, I think the actual QKD startups that are 
serious *are* trying to work within the crypto/security communities, at 
least as best they can figure out; there is quite a bit over on the ITU 
side.
>
> One comment:
>
> "because the problem it solves -- generating shared random or 
> near-random bits secure enough to be used as encryption keys"
>
> While quantum researchers think QKD solves that problem, I don't think 
> this is correct. It is well-established security practice to never use 
> TRNG output directly and I don't think that will ever change. QKD is 
> providing unauthenticated key exchange. If QKD is ever practically 
> used, the output (secret entropy) of QKD would be input to a classical 
> KDF/CSPRNG. The output from the KDF/CSPRNG would be used in an AEAD 
> with information-theoretic or computational-theoretic security. See 
> e.g., BSI TR-02102-1 [1]:  "Irrespective of this, the BSI does not and 
> will not recommend the use of the one-time pad alone with keys 
> obtained via QKD or via other key agreement mechanisms in the future."
>
Thanks for all that! Noted and updated on the blog.
>
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=7
>