Re: [Qirg] qirg - Requested session has been scheduled for IETF 108

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 06 September 2021 22:26 UTC

Return-Path: <touch@strayalpha.com>
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 D5C253A1A39 for <qirg@ietfa.amsl.com>; Mon, 6 Sep 2021 15:26:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 yjEbhHkrQsPI for <qirg@ietfa.amsl.com>; Mon, 6 Sep 2021 15:26:40 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99493A1A30 for <qirg@irtf.org>; Mon, 6 Sep 2021 15:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bIqZG3fVaWP0R01lzcS9GtRgasBYoH/Qnkp/lvWATqc=; b=kDObubGQ/m6a4TqRS2dmVtAXBJ EZiurcE1vY3kqjnqp2yGGAJ9ptoOcH2f4fWtWw7P8/n6EC5BrtUogseWtb8jIblqsOi0psLMn6JCG PltqR4Bz1tM9wZf/PO/MCnw+R2vcuFG9zQuTYgBoRJWfi2BxeVdGZb60QbL6B6t/HaBWYzENE3xMt UCFdbZSgCRbXrhZRcFs9rua4U+i4vF26z0f+WBZXSYsQ6uDvIQlZLCFBmFiL0fRDUDZxMrvJmEUok ejf+jxriEd1rhYgpRZy495YzQ9hb+aMjhtzidJES+h8g+tWZe3D3o1gn3LeGtx9tP3aFw1fAk6gQP Qa06lejg==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:61745 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1mNN4T-00AEsW-R1; Mon, 06 Sep 2021 18:26:38 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8D678682-B18D-4AD3-AB89-49DEE1B8E9CD"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <BL3PR11MB5682176B8FCF9626CE616C6BC1D29@BL3PR11MB5682.namprd11.prod.outlook.com>
Date: Mon, 06 Sep 2021 15:26:30 -0700
Cc: Gelard Patrick <Patrick.Gelard@cnes.fr>, "w.kozlowski@tudelft.nl" <w.kozlowski@tudelft.nl>, "qirg@irtf.org" <qirg@irtf.org>
Message-Id: <43ED542B-D09E-4B9C-8121-D7BEFE243762@strayalpha.com>
References: <159373563611.30173.15922651637659746852@ietfa.amsl.com> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CCC7CAA1D@TW-MBX-P03.cnesnet.ad.cnes.fr> <BL3PR11MB5682D308AEFB20221C9ADE1EC1D29@BL3PR11MB5682.namprd11.prod.outlook.com> <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CCC7CAA5A@TW-MBX-P03.cnesnet.ad.cnes.fr> <BL3PR11MB5682176B8FCF9626CE616C6BC1D29@BL3PR11MB5682.namprd11.prod.outlook.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/ZMXTxpUpPQwC-V3qAAPRYINVijo>
Subject: Re: [Qirg] qirg - Requested session has been scheduled for IETF 108
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Quantum Internet RG <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2021 22:26:46 -0000

OTP is the name of the encryption algorithm that *uses* a key.

The key it uses could be preconfigured and then endpoints separated, distributed using a physical media ("sneaker net”), distributed over-the-air (OTA), either using an existing encryption algorithm (e.g., AES), or generated at endpoints using QKD (QKD is really QKG; it doesn’t distribute a given key, it computes a key at both endpoints).

Nothing about OTP specifies which of these are used per se, though the benefits of using OTP would be somewhat undermined by using OTA.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 6, 2021, at 2:49 PM, Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org> wrote:
> 
> It appears that I assumed the term "OTP" had a different meaning than what was intended.
> 
> Where I'm from, an OTP is a process where both the sender and the receiver share a large preconfigured set of random bits (generally produced at a central site and physically transported securely); they use those bits to protect the data (encryption usually by XOR; integrity protection can be done but is a little more complicated (universal hash)).  Any other process for generating those bits on the two sides, be it QKD or a deterministic cryptographical process, is specifically not an OTP.
> 
> Obviously, you're using OTP to include any mechanism to share the bits (specifically including QKD).
> 
> With my meaning of OTP, there are obviously logistical problems (not unsolvable, but are also nontrivial), hence my puzzlement on whether those were considered solved (at least for part of the network).
> 
> -----Original Message-----
> From: Gelard Patrick <Patrick.Gelard@cnes.fr> 
> Sent: Monday, September 6, 2021 12:43 PM
> To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>; w.kozlowski@tudelft.nl; qirg@irtf.org
> Subject: RE: [Qirg] qirg - Requested session has been scheduled for IETF 108
> 
> Dear Scott Fluhrer,
> 
> QKD allows two distant entity  to share a secret, protected from listening by property of the quantum world, which can then be used for a secret key cryptosystem like OTP but also AES (Advanced Encryption Standard).
> 
> Best regards
> Patrick
> 
> -----Message d'origine-----
> De : Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> Envoyé : lundi 6 septembre 2021 18:27 À : Gelard Patrick <Patrick.Gelard@cnes.fr>; w.kozlowski@tudelft.nl; qirg@irtf.org Objet : RE: [Qirg] qirg - Requested session has been scheduled for IETF 108
> 
> Ok, I'll ask the obvious question: if we assume that we have a deployable OTP system available, what does QKD bring to the table?  QKD's claim to fame is that its security is based on QM; OTP has an even better security guarantee (informational; that is, the attacker literally does not have enough information to attack the system).  Given that OTP does not have QKD's downsides (e.g. cost, range limitations, or restrictions to certain types of media), why would we use QKD?
> 
> -----Original Message-----
> From: Qirg <qirg-bounces@irtf.org> On Behalf Of Gelard Patrick
> Sent: Monday, September 6, 2021 11:28 AM
> To: w.kozlowski@tudelft.nl; qirg@irtf.org
> Subject: Re: [Qirg] qirg - Requested session has been scheduled for IETF 108
> 
> Dear Wojciech 
> 
> This very interesting overview shows a considerable work, now QKD Network seem to be more oriented to "Trusted Node Network Relay" than Entanglement Swapping. In this scheme, key are stored in QKD nodes (trusted nodes) and relayed to other distant QKD nodes via highly secure encryption, with OTP (one-time-pad) recommended. 
> 
> Best regards
> Patrick
> 
> -----Message d'origine-----
> ---------- Message transféré ---------
> De : Wojciech Kozlowski <W.Kozlowski@tudelft.nl> Date : lun. 6 sept. 2021 à 10:48 Objet : [Qirg] Liaison statement from ITU À : qirg@irtf.org <qirg@irtf.org>
> 
> Dear QIRG,
> 
> The ITU-T SG-13 have sent the QIRG a liaison statement: [sp16-sg13-oLS-00213] LS on work progress on Quantum Key Distribution (QKD) network in SG13 (as of July 2021).
> 
> You can view the full text and attachments on the datatracker: https://datatracker.ietf.org/liaison/1752/.
> 
> My brief take on it is that it is a very interesting snapshot of the ITU's current QKD network standardization efforts.
> 
> Thanks,
> Wojtek
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg