Re: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04

Bruno Rijsman <brunorijsman@gmail.com> Thu, 17 June 2021 06:04 UTC

Return-Path: <brunorijsman@gmail.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 DBC7F3A0C02 for <qirg@ietfa.amsl.com>; Wed, 16 Jun 2021 23:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 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, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 A_dIRnHOH4gc for <qirg@ietfa.amsl.com>; Wed, 16 Jun 2021 23:04:26 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0EF3A0C06 for <qirg@irtf.org>; Wed, 16 Jun 2021 23:04:25 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id l1so7773805ejb.6 for <qirg@irtf.org>; Wed, 16 Jun 2021 23:04:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7ht0+SYkBG2+o/eFBBH+xXoswM2WWtq+Ch9D7w4+hKM=; b=OWT+Gcj9Cz1GG/0GUV+XHZazyPni1hhTF/SI4kM2MVxEeapFLqhpl9f322j1gKtBXH 4hnA4QEN/zcEk2zCrFDE2kIQVlF8LrWZIRtaHEkQdG4OmR4U41mUwFZnDixMr0IESd6c 1+4RPh/5JoBXg1DEEl/4dSjXZDFu5oSH5v+QKZIMlTdqf21cCpmDLuuPvxvgCQJtAjVX L1JpPpYzOCY/2wrnYnzIemUAWwvqBAO+/j6l5yKHu4alETNtYLZkO/36hiy5RzKhH+AT di9r4aahHMS7vorRYR/ytm9tBtNei7SK4ili7iXnEYrWPyC/SmFQx9pjcAaajRlOAmju C5iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7ht0+SYkBG2+o/eFBBH+xXoswM2WWtq+Ch9D7w4+hKM=; b=FY6YL11TP7f9F/l0uotwY8TW8LnnP7e0idBW/vUYG+aEy9rTIHM9wa3hjyjm+1/Qo8 IBZ7uQGVdlIsNcLy9SRhwwK9Xj7jGpt2cbhijZ6VBPkT9K8fLnPvCkKtQBqCNcFmNoh2 uXYf5GAR2xdqKTHBZ3LgF/D1qPx3Vi3aYU4y/Igz+BsmFwzYrLOcBSOSXBWl80F333b3 WzHVCd78r0I2qZZ0iEWa9ofgExWcWdu+JKCjC8cWz+bEUG9Hu1mnQyekb1cRLpExlOGP WZ8XWmzqD4nGe5wJnLcUnlq6ybpoJRfd9NsLkLngamkwk94j8/vObHUmpzH990RVVsZr YMuw==
X-Gm-Message-State: AOAM532K2dLlJY9A4qJXM712vjQict0fwoA0VluSdFVrlFNj/XQvWviO 1XrtI5LjP987VB1qugWVQ4Y=
X-Google-Smtp-Source: ABdhPJx3qv8N7JQUN8Lfkc9EjuevMskcf6ykKittH1PhHzSo9JMlzUU0yzS9NKaG7x1llKvwWNeJXw==
X-Received: by 2002:a17:907:ea4:: with SMTP id ho36mr3293682ejc.230.1623909862922; Wed, 16 Jun 2021 23:04:22 -0700 (PDT)
Received: from [10.0.0.31] (62-11-2-177.dialup.tiscali.it. [62.11.2.177]) by smtp.gmail.com with ESMTPSA id og26sm463905ejc.52.2021.06.16.23.04.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jun 2021 23:04:22 -0700 (PDT)
From: Bruno Rijsman <brunorijsman@gmail.com>
Message-Id: <C70FCACC-45D7-4C0E-85E0-BF02363ED2D5@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_254C0EDA-BDA0-4CE3-8C2B-7B55B1413652"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 17 Jun 2021 08:04:20 +0200
In-Reply-To: <CALxNLBivSeeZ8UZSdR0mwK4fp_ECgzfkF5hVQ3--4VMj6EveuQ@mail.gmail.com>
Cc: draft-irtf-qirg-quantum-internet-use-cases@ietf.org, qirg@irtf.org
To: Melchior Aelmans <melchior@aelmans.eu>
References: <E2379064-70A3-47C7-8AE2-49682BDDE052@ericsson.com> <MN2PR10MB3485BC586EB476A3B78E22EDF87E9@MN2PR10MB3485.namprd10.prod.outlook.com> <BE5D5B52-6DD6-4B36-94D5-0B65FAA5D4CB@sfc.wide.ad.jp> <MN2PR10MB34852555401F25DA62249103F85B9@MN2PR10MB3485.namprd10.prod.outlook.com> <CALxNLBivSeeZ8UZSdR0mwK4fp_ECgzfkF5hVQ3--4VMj6EveuQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/nkW-C3cYzvlqL3q6bMdTpFiWR8U>
Subject: Re: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04
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: Thu, 17 Jun 2021 06:04:32 -0000

Hi Melchior,

Section 5.2 in the draft already covers the need a classical communication channel parallel to the quantum communication channel. Did you want to add something to this section?

With respect to the cost issue, there was an earlier exchange on this mailing list about whether or not we should discuss multiplexing (which has several meanings, and one of those is multiplexing classical and quantum communication channels over the same fiber).  I believe the outcome of that e-mail discussion was to leave it out of the draft (although I voted the other way ;-)

The draft currently does not discuss post quantum cryptography (PQC) or any other classical protocol for exchanging keys "in a quantum-safe manner".  I think that makes sense, since these protocols are pure classical protocols; the only relation to quantum is that they are quantum safe (i.e. their safely on the computational complexity of mathematical problems that turn out to be not so complex for quantum computers). 

Clock synchronization is mentioned as a use case in section 3.2.2 of the use case draft.

— Bruno

> On Jun 16, 2021, at 10:55 PM, Melchior Aelmans <melchior@aelmans.eu> wrote:
> 
> Dear co-authors, QIRG,
> 
> I have a couple of suggestions for the draft:
> 
> We might want to describe the classical internet supporting the Quantum Internet. For example, current QKD is point-to-point where a dedicated (dark)fiber is needed between 2 QKD boxes and a separate datachannel for the QKD boxes to synchronise. This is very costly and resource intensive. So might not be scalable or affordable. Some companies like Arqit and Quantum Xchange are working on SDN like solutions to distribute quantum generated keys acros a non-quantum link. The question is if it's then still QKD, even when leveraging a post-quantum key distribution method it's not quantum but math and so potentially breakable (at least eavesdropping is possible without it being known). However this might be a deployable solution so we should take it into consideration.
> 
> Also we might want to address 5G/self-driving cars use cases where timing is critical. The exact timing is something quantum could provide perhaps?
> 
> Any ideas on this? I think it might be worth thinking about it and perhaps address it in the draft.
> 
> Cheers,
> Melchior
> 
> On Mon, May 3, 2021 at 3:08 PM Chonggang Wang <Chonggang.Wang@interdigital.com <mailto:Chonggang.Wang@interdigital.com>> wrote:
> Hello Rodney,
> 
>  
> 
> Thank you for the good suggestion.
> 
>  
> 
> We replaced the Fitzi paper with the two references you suggested. For that, we also added the following sentence
> 
>  
> 
> “A quantum aided Byzantine agreement on quantum repeater networks as proposed in [Taherkhani] includes optimization techniques to greatly reduce the quantum circuit depth and the number of qubits in each node.”
> 
>  
> 
> Please refer to the new v06 of our document.
> 
> https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/>
>  
> 
> Best regards,
> 
> Chonggang
> 
>  
> 
> From: Rodney Van Meter <rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>> 
> Sent: Tuesday, March 30, 2021 6:43 AM
> To: Chonggang Wang <Chonggang.Wang@InterDigital.com>
> Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>>; John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@dmarc.ietf.org>>; qirg@irtf.org <mailto:qirg@irtf.org>
> Subject: Re: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04
> 
>  
> 
> Chonggang,
> 
>  
> 
> <list member hat on>
> 
> One comment:
> 
> The reference to the Fitzi paper on Byzantine agreement: I’ve read that paper, and I don’t recall all of the details, but my impression from it in (vague, fading) memory is that it doesn’t really solve the problem it’s claiming to solve, and certainly isn’t a full Byzantine agreement protocol, despite the title.  It’s more like “detectable broadcast”, and I’m not entirely sure how to use it.
> 
>  
> 
> There is another quantum Byzantine agreement protocol by Hassidim & Ben-Or, which a visiting student to my group did some analysis of a few years ago.  (In fact, Amin might be on the list here?)  I think that’s a more useful approach, though we found that the implementation costs are high and I’m still not sure it’s useful in practice.
> 
>  
> 
> @inproceedings{ben-or2005fast,
> 
>   title={{Fast quantum Byzantine agreement}},
> 
>   author={Ben-Or, M. and Hassidim, A.},
> 
>   booktitle={Proceedings of the thirty-seventh annual ACM symposium on Theory of computing},
> 
>   pages={481--485},
> 
>   isbn={1581139608},
> 
>   year={2005},
> 
>   organization={ACM},
> 
>   comment = {Should be citeable as an application of distributed QC.
> 
>                   Uses secure multi-party communication protocol of
> 
>                   Crepeau, Gottesman and Smith, known as QVSS.}
> 
> }
> 
>  
> 
> @article{taherkhani18:qba,
> 
>   author={Mohammand Amin Taherkhani and Keivan Navi and Rodney Van{ }Meter},
> 
>   title={Resource-aware system architecture model for implementation of quantum aided Byzantine agreement on quantum repeater networks},
> 
>   journal={Quantum Science and Technology},
> 
>   volume={3},
> 
>   number={1},
> 
>   pages={014011},
> 
>   url={http://stacks.iop.org/2058-9565/3/i=1/a=014011 <http://stacks.iop.org/2058-9565/3/i=1/a=014011>},
> 
>   year={2018},
> 
>   abstract={Quantum aided Byzantine agreement is an important distributed quantum algorithm with unique features in comparison to classical deterministic and randomized algorithms, requiring only a constant expected number of rounds in addition to giving a higher level of security. In this paper, we analyze details of the high level multi-party algorithm, and propose elements of the design for the quantum architecture and circuits required at each node to run the algorithm on a quantum repeater network (QRN). Our optimization techniques have reduced the quantum circuit depth by 44\% and the number of qubits in each node by 20\% for a minimum five-node setup compared to the design based on the standard arithmetic circuits. These improvements lead to a quantum system architecture with 160 qubits per node, space-time product (an estimate of the required fidelity) {${KQ}\approx 1.3\times {10}^{5}$} per node and error threshold {$1.1\times {10}^{-6}$} for the total nodes in the network. The evaluation of the designed architecture shows that to execute the algorithm once on the minimum setup, we need to successfully distribute a total of 648 Bell pairs across the network, spread evenly between all pairs of nodes. This framework can be considered a starting point for establishing a road-map for light-weight demonstration of a distributed quantum application on QRNs.}
> 
> }
> 
>  
> 
>  
> 
> Rodney Van Meter
> 
> rdv@sfc.wide.ad.jp <mailto:rdv@sfc.wide.ad.jp>
> Professor, Faculty of Environment and Information Studies, Keio University, Japan
> 
> 
> 
> 
> On Mar 30, 2021, at 8:19, Chonggang Wang <Chonggang.Wang@InterDigital.com <mailto:Chonggang.Wang@InterDigital.com>> wrote:
> 
>  
> 
> Hi John,
> 
> Thank you very much for your detailed review and useful comments/questions. We have incorporated your feedback in the new version of this document, which was just uploaded as v05 (https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/ <https://datatracker.ietf.org/doc/draft-irtf-qirg-quantum-internet-use-cases/>)
> 
> I also inserted some inline responses [CW] below to explain the changes we have made to v05. Please let us know if you have any further feedback.
> 
> Best regards,
> Chonggang
> 
> -----Original Message-----
> From: Qirg <qirg-bounces@irtf.org <mailto:qirg-bounces@irtf.org>> On Behalf Of John Mattsson
> Sent: Thursday, March 11, 2021 6:37 PM
> To: qirg@irtf.org <mailto:qirg@irtf.org>
> Subject: [Qirg] Review of draft-irtf-qirg-quantum-internet-use-cases-04
> 
> 
> 
> Review of draft-irtf-qirg-quantum-internet-use-cases-04
> 
> Hi,
> 
> I think this is a useful document. I do not think it is ready for RGLC yet but it is getting close.
> 
> Cheers,
> John
> 
> 
> Comments:
> 
> 
> - Section 1
> "The connections between the various nodes in the Internet include Digital Subscriber Lines (DSLs), fiber optics, coax cable and wireless that include Bluetooth, WiFi, cellular (e.g., 3G, 4G, 5G), satellite, etc."
> This seems too focused on last mile Internet access.
> [CW] Rephased the sentences as the following one:
> “The connections between the various nodes in the Internet include backbone links (e.g., fiber optics), access links (e.g., WiFi, cellular wireless), etc.”
> 
> - Section 1
> ”It is anticipated that the Quantum Internet will provide intrinsic benefits such as improved end-to-end and network security.”
> I would remove "anticipated" and "will". I don't think I have heard anybody working with security believed that QKD will provide much practical benefits. I mostly see it as something quantum network researchers do because they cannot do anything else yet. If you want to make such claims, I think you should ask CFRG or the security area in IETF.
> https://www.schneier.com/essays/archives/2008/10/quantum_cryptography.html <https://www.schneier.com/essays/archives/2008/10/quantum_cryptography.html>
> https://www.schneier.com/blog/archives/2018/08/gchq_on_quantum.html <https://www.schneier.com/blog/archives/2018/08/gchq_on_quantum.html>
> https://www.nsa.gov/what-we-do/cybersecurity/quantum-key-distribution-qkd-and-quantum-cryptography-qc/ <https://www.nsa.gov/what-we-do/cybersecurity/quantum-key-distribution-qkd-and-quantum-cryptography-qc/>
> [CW] Okay.  The whole sentence in question was deleted.  The rest of the document does not depend on this statement and since it is causing confusion it is best to just delete it.
> 
> The document should also bring up denial of service risks and the requirement for trusted relays. These are areas where a Quantum Internet is expected to provide intrinsic security disadvantages.
> [CW] Trusted relays are discussed in multiple sections starting in section 5.1 onwards, so it is already well covered in the document.  On the point of denial of service risk, is there a specific reference that you could point us to?
> 
> - Section 1
> "unique physical principles"
> Is unique the right word here?
> [CW] Changed the whole sentence to the following one:
> “The Quantum Internet will operate according to quantum physical principles such as quantum superposition and entanglement.”
> 
> - Section 2
> The document does not seem to use any of the words. I don't know if an Informational IRTF docuement needs this section at all but if it does it should refer to RFC 8174 as well
> [CW] Okay.  We checked some other Informational IRTF RFCs and they do not have this section.  So, the section was deleted.
> 
> - Section 3
> "i.e. fundamental unit of information in a classical computer"
> Bit is equally much a unit of informaiton in communication .
> [CW] Good point. Updated the definition below:
> “Bit - Binary Digit (i.e., fundamental unit of information in classical communications and classical computing)”
> 
> - Section 3
> "from 50 to a few hundred qubits"
> Logical or physical qubits?
> [CW] Changed it to physical qubits.
> 
> - Section 3
> "classical bits, or the measured state of qubits."
> They would still be classic bits
> [CW] Yes. Clarified the definition accordingly.
> “Packet - Formatted unit of multiple related bits. The bits contained in a packet may be classical bits, or the measured state of qubits in classical bits.”
> 
> - Section 3
> "to securely distribute security keys from a sender to a receiver."
> I would more say that QKD let the two securely establish/agree on a key.
> [CW] Clarified the definition as suggested.
> “Quantum Key Distribution (QKD) - A method that leverages quantum mechanics such as no-cloning theorem to let two parties (e.g., a sender and a receiver) securely establish/agree on a key.”
> 
> - Section 3
> OLD "The Quantum Internet will be merged into the Classical Internet to form a new Hybrid Internet"
> NEW "The Quantum Internet is expected to be merged into the Classical Internet to form a new Hybrid Internet"
> [CW] Thanks for the good suggestion and made the change accordingly.
> 
> - Section 3
> "fundamental unit of information in a quantum computer"
> Qubit is equally much a unit of informaiton in communication .
> [CW] Good point. Updated the definition below:
> “Qubit - Quantum Bit (i.e., fundamental unit of information in quantum communication and quantum computing). ….”
> 
> - Section 4.2.
> "Quantum cryptography applications - Refers to the use of quantum information technology to ensure secure communications"
> Just like classic cryptography, Quantum cryptography is much more than securing communication https://en.wikipedia.org/wiki/Quantum_cryptography <https://en.wikipedia.org/wiki/Quantum_cryptography>
> [CW] Good point. Rephased the sentence below:
> “Quantum cryptography applications - Refers to the use of quantum information technology for cryptographic tasks such as quantum key distribution and quantum commitment.”
> 
> - Section 4.2.
> "sensors or Internet of Things (IoT) devices"
> sensors are typically IoT devices.
> [CW] Removed “or Internet of Things (IoT) devices”.
> 
> - Section 4.3.
> "to share a secret key"
> Probably good to explain to people that the key is a classic key.
> [CW] Agreed. Changed it to “… share a classical secret key …”.
> 
> - Section 5.1
> "This results in a source quantum node A at Bank #1 to securely send a classic secret key to a destination quantum node B at Bank #2."
> I don't think that is a correct description of QKD. Maybe use "establish” or ”agree”
> [CW] Adopted “establish" and revised the original sentence below
> “This results in a source quantum node A at Bank #1 to securely establish a classical secret key with a destination quantum node B at Bank #2.”
> 
> - Section 5.1
> "One requirement for this secure communication setup process is that it should not be vulnerable to any classical or quantum computing attack."
> Most of the attacks discussed on QKD has been more physical. It would be good if the document discussed other types of attacks then computing attacks. Wikipedia does e.g. mention the following: "The first attack that claimed to be able to eavesdrop the whole key [70] without leaving any trace was demonstrated in 2010. It was experimentally shown that the single-photon detectors in two commercial devices could be fully remote-controlled using specially tailored bright illumination. "
> [CW] Okay.  Added the following text:
> "One requirement for this secure communication setup process is that it should not be vulnerable to any classical or quantum computing attack.  This can be realized using QKD [ETSI-QKD-Interfaces] which   has been mathematically proven to be unbreakable.  QKD can securely establish a secret key between two quantum nodes, without physically transmitting the key through the network and thus achieving the required security.  However, care must be taken to ensure that the QKD system is safe against physical attacks which can compromise the system. An example of a physical attack is when an attacker is able to surreptitiously inject additional light into the optical devices used in QKD to learn side information about the system such as the polarization.  Other specialized physical attacks against QKD have also been developed such as the phase-remapping attack, photon number splitting attack, and decoy state attack [Zhao]."
> 
> - Section 5.1
> This section should mention authentication, which is a cornerstone in almost all security protocols.
> [CW] Added the following paragraph to Section 5.1
> “The post-processing procedure needs to be performed over an authenticated classical channel. In other words, the source quantum node and the destination quantum node need to authenticate the classical channel to make sure there is no eavesdroppers or man-in-the-middle attacks, according to certain authentication protocols such as [Kiktenko]. In [Kiktenko], the authenticity of the classical channel is checked at the very end of the post-processing procedure instead of doing it for each classical message exchanged between the quantum source node and the quantum destination node.”
> 
> - Section 5.1
> "The source quantum node A transforms the secret key to qubits."
> I don't think the random bits should be called a "key" at this point
> [CW] Agreed and updated the sentence to the following one:
> “The source quantum node A transforms classical bits to qubits. Basically, for each classical bit, the source quantum node A randomly selects one out of two bases and uses the selected basis to prepare/generate a qubit for the classical bit.”
> 
> - Section 6.1
> "a current 20-qubit machine"
> Would be good to inform the reader if these are physical or logical qubits.
> [CW] Changed it to “…a current 20-physical-qubit machine …”.
> 
> - Security 9
> "because of the exponential increase of computing power with quantum computing"
> This seems like a press release from someone selling a quantum computer.
> I don’t think the claim is correct for integer factorization and discrete logarithm problem. The running time of GNFS is sub-exponetial and the running time of Shor is n^3 so the speedup should also be sub-exponential. Maybe correct for ECDLP.
> [CW] Okay.  Changed to “because of the increase in computing ability with quantum computing for certain classes of problems (e.g., prime factorization, optimizations).”  Also, re-worked the entire paragraph to make it clear that the threat/solution is specifically for Diffie-Hellman type public-key encryption systems.
> 
> - Security 10
> ”Paradoxically, development of the Quantum Internet will also mitigate the threats posed by quantum computing attacks against public-key cryptosystems.”
> That is not true. QKD can only replace an unauthenticated Diffie-Hellman Exchange. The Quantum Internet will not do anything to mitigate the threats against digital signatures used in e.g. DNSSEC, TLS, IPsec, firmware updates, etc...
> [CW] Okay. Changed to be more precise: “Interestingly, development of the Quantum Internet will also mitigate the threats posed by quantum computing attacks against Diffie-Hellman based public-key encryption systems.”
> 
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org <mailto:Qirg@irtf.org>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
> [Banner]
> 
> [Banner]<https://www.interdigital.com/features/sustainability-in-a-wireless-world <https://www.interdigital.com/features/sustainability-in-a-wireless-world>>
> 
> Sustainability in a Wireless World: Research dedicated to understanding the impact of our technologies on the planet.<https://www.interdigital.com/features/sustainability-in-a-wireless-world <https://www.interdigital.com/features/sustainability-in-a-wireless-world>>
> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org <mailto:Qirg@irtf.org>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
>  
> 
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org <mailto:Qirg@irtf.org>
> https://www.irtf.org/mailman/listinfo/qirg <https://www.irtf.org/mailman/listinfo/qirg>
> _______________________________________________
> Qirg mailing list
> Qirg@irtf.org
> https://www.irtf.org/mailman/listinfo/qirg