Subject: [Qirg] Support for QIRG

From: John Mattsson <[email-masked]>
Date: Wed, 21 Mar 2018 11:45:50 +0000

Hi,
    
I liked the presentations today, I have seen far too many presentations on Quantum communication/networks talk way too much about QKD (which I think is kind of a niche product). Your presentation brought up the differences between unentangled and entangled networks and gave a good overview of the many interesting use cases for entangled quantum networks. As you stated, many of the research groups doing quantum communication has little knowledge of networking and security. I think the suggested scope for QIRG is very good and I strongly support the creation of this proposed RG, hopefully it will attract attention from more researchers in quantum communication.  
    
Some questions/comments on backup slide 19:
    
- What does 1 bit/sec mean for D-H + AES? you can clearly do get 10^11 bit/sec (or more) for a classical connection today.
    
- You have the three phases "Factoring becomes possible", "AES broken", "testing all keys becomes possible". Agree that "Factoring becomes possible" will clearly happen as soon as someone build a large enough quantum computer. What is the difference between "AES broken" and "testing all keys becomes possible", and what do you mean with "feasible today in metro nets"? Breaking AES is clearly unfeasible today. Breaking AES-256 will definitely always be infeasible with Grover's algorithms and it is unclear if breaking AES-128 will ever be practical with quantum computers (the depth of the quantum circuit will be very large).
    
- You should add (PQC running on classical computer, e.g. lattice bases) + AES to the slide. That's seen as the main way forward in the security community.
    
Cheers,
John

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 21 Mar 2018 21:03:05 +0900

Thanks for the positive comments.

Will answer your questions about the backup material tomorrow on QIRG only — doesn’t seem like something that needs to be on irtf-discuss, unless you or someone else feels otherwise.  Speaking of which, irtf-discussers, please join us on the QIRG mailing list if you are interested in helping hammer out the charter!

		—Rod

> On Mar 21, 2018, at 8:45 PM, John Mattsson <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---

From: Rodney Van Meter <[email-masked]>
Date: Thu, 22 Mar 2018 22:50:43 +0900

[irtf-discuss removed from cc:, this seems a little into the weeds for that ML, but if you think it’s still valuable over there, feel free to fwd or cc on a reply.]

[We now have a bunch of new folks on the list, so FYI, slides from my talk yesterday are at
 https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-van-meter-and-wehner-vision-for-a-quantum-internet-research-group-02 <https://datatracker.ietf.org/meeting/101/materials/slides-101-irtfopen-van-meter-and-wehner-vision-for-a-quantum-internet-research-group-02>
via https://datatracker.ietf.org/meeting/materials/] <https://datatracker.ietf.org/meeting/materials/%5D>

[Also, meta-comment, I’m happy to dive into the technical work of the RG, which I view as very much including the kind of discussion in this email, but an early priority is to hammer out a charter, propose RG chairs, and do whatever else we need to do to get Allison & the IRSG to approve us.]

> I liked the presentations today, I have seen far too many presentations on Quantum communication/networks talk way too much about QKD (which I think is kind of a niche product). Your presentation b…

Thanks for the positive comments. I’ll get around to sending some pointers to some of those other uses for a QI soon.
> - What does 1 bit/sec mean for D-H + AES? you can clearly do get 10^11 bit/sec (or more) for a classical connection today.

Thanks for digging that deep into the slide set. This requires a little bit of explanation that I didn’t get into in the presentation, and even at that, it’s a little ad hoc.

The point here was not, “What bandwidth can you achieve using approach X?” The point of the slide is, “How many secure bits per second does QKD have to deliver in order to be useful in this environment?”

For that, I thought, “If you’re using QKD+AES, what’s the fastest reasonable rate at which you might want to do key rollover?” and rather arbitrarily settled on once every few minutes.  If you’re using a 128-bit key, and your QKD system generates one good, error corrected, eavesdropper-clean, privacy-amplified bit per second, that gives you rollover once every two minutes.  A 256-bit key would rollover once every four minutes.

There’s enough overhead in the rollover that you probably don’t want to do it on the order of a second or less. I’ve worked on an IPsec implementation, but not done a lot of real-world operational use of it; I gather that key lifetimes of 86,400 seconds (24 hours) and 3,600 seconds (one hour) are common. You could ramp down your QKD performance demands that low, if you like, but that seems to severely under-utilize even the modest capabilities of existing unentangled QKD systems, and seems reasonable for entangled systems.

At the upper end, nobody is likely to turn on one-time pad via QKD until you can do a gigabit per second or so, and as you point out existing systems beat that by a couple of orders of magnitude.

So the real meta-message of this slide is that QKD offers a set of utilization scenarios with increasing security as the QKD performance increases.  It gives us a pathway for useful quantum networks: we can point to reasonable use cases covering nine or more decimal orders of magnitude in performance. Low-performance systems can be useful, and high-performance systems more useful.

Beyond that, we can work through the individual cases in more detail, but that’s really the message.

And of course as you’ve already grasped but left unsaid, the working assumption here is that recording encrypted traffic today and decrypting it some years from now is an interesting attack, which of course depends on your use case. Some people have proposed using QKD e.g. to harden the real-time control networks for power plants, but I don’t think that’s a good use case; in twenty years, nobody cares that you tweaked the phase Monday afternoon and upped the output Tuesday morning. But banking is a little stronger case, and diplomatic/military communication stronger still.

> 
> - You have the three phases "Factoring becomes possible", "AES broken", "testing all keys becomes possible". Agree that "Factoring becomes possible" will clearly happen as soon as someone build a large enough quantum computer.

Or somebody finds a flaw in Diffie-Hellman. (“Factoring” includes “discrete logarithm” in this context. Hopefully no one will make me justify that :-).)

> What is the difference between "AES broken”

e.g., somebody finds a flaw in AES.

> and "testing all keys becomes possible”,

For any symmetric crypto system, if it somehow magically becomes possible to test all possible key candidates in a reasonable time, then all symmetric crypto is busted. No one I know is suggesting this is possible, it’s a strawman hypothetical.

> and what do you mean with "feasible today in metro nets”?

You can go buy boxes that do this today from one of those startups in an earlier slide, and deploy them over metro-area networks. It takes a fair bit of coin and the usual amount of patience with bleeding-edge tech, but it’s possible.

> Breaking AES is clearly unfeasible today. Breaking AES-256 will definitely always be infeasible with Grover's algorithms and it is unclear if breaking AES-128 will ever be practical with quantum computers (the depth of the quantum circuit will be very large).

Agreed, and fully error-corrected QCs remain a ways off, at best. But I reserve the right to change my opinion if someone as smart as Peter Shor or Lov Grover comes up with another quantum or classical algorithm that presents a plausible attack.

> - You should add (PQC running on classical computer, e.g. lattice bases) + AES to the slide. That's seen as the main way forward in the security community.

Good point, it’s probably time to update that slide. Other than adding the pointer to weakdh.org <http://weakdh.org/>, this slide hasn’t evolved much in the last several years. It’s already a lot for non-specialists to grasp, though, and I don’t want to make it too complicated.

		—Rod

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Mar 2018 16:41:59 +0000

I'm not Allison Mankin, so please take this for what it's worth, but
Allison and I are Facebook friends, so she can excoriate me there ...

On Thu, Mar 22, 2018 at 1:50 PM, Rodney Van Meter <[email-masked]>
wrote:

> [irtf-discuss removed from cc:, this seems a little into the weeds for
> that ML, but if you think it’s still valuable over there, feel free to fwd
> or cc on a reply.]
>
>  https://datatracker.ietf.org/meeting/101/materials/slides-
> 101-irtfopen-van-meter-and-wehner-vision-for-a-quantum-
> internet-research-group-02
> via https://datatracker.ietf.org/meeting/materials/]
>
> [Also, meta-comment, I’m happy to dive into the technical work of the RG,
> which I view as very much including the kind of discussion in this email,
> but an early priority is to hammer out a charter, propose RG chairs, and do
> whatever else we need to do to get Allison & the IRSG to approve us.]
>

As IRTF Chair, Allison is continuing the Lars Eggert "act like a research
group for a year, and we'll see if you are one" model for proposed working
groups. Because that's true, my suggestion is to do enough work on the
charter to allow you to attract and engage with other researchers, which is
one of the key points for moving a proposed research group to an approved
research group, but you don't have to have a lot of precision in the
charter, early on. Suggesting good chairs is definitely a good thing to do,
too. But acting like a research group matters a lot. For instance,
identifying where the proposed research group will meet at conferences or
other opportunities to engage researchers and then engaging them, would be
great.

(When I joined the IRSG in 2014, Lars was getting proposed charters that
were exactly like they would have been for an IETF working group. That's
one of the reasons he moved to the "mailing list, room, and a year to prove
you're a research group" model after a year or two. I know a lot of IRTF
participants realize that, but I bet not everyone does)

Spencer

> I liked the presentations today, I have seen far too many presentations on
> Quantum communication/networks talk way too much about QKD (which I think
> is kind of a niche product). Your presentation brought up the differences
> between unentangled and entangled networks and gave a good overview of the
> many interesting use cases for entangled quantum networks. As you stated,
> many of the research groups doing quantum communication has little
> knowledge of networking and security. I think the suggested scope for QIRG
> is very good and I strongly support the creation of this proposed RG,
> hopefully it will attract attention from more researchers in quantum
> communication.
>
>
> Thanks for the positive comments. I’ll get around to sending some pointers
> to some of those other uses for a QI soon.
>
>
> - What does 1 bit/sec mean for D-H + AES? you can clearly do get 10^11
> bit/sec (or more) for a classical connection today.
>
>
> Thanks for digging that deep into the slide set. This requires a little
> bit of explanation that I didn’t get into in the presentation, and even at
> that, it’s a little ad hoc.
>
> The point here was not, “What bandwidth can you achieve using approach X?”
> The point of the slide is, “How many secure bits per second does QKD have
> to deliver in order to be useful in this environment?”
>
> For that, I thought, “If you’re using QKD+AES, what’s the fastest
> reasonable rate at which you might want to do key rollover?” and rather
> arbitrarily settled on once every few minutes.  If you’re using a 128-bit
> key, and your QKD system generates one good, error corrected,
> eavesdropper-clean, privacy-amplified bit per second, that gives you
> rollover once every two minutes.  A 256-bit key would rollover once every
> four minutes.
>
> There’s enough overhead in the rollover that you probably don’t want to do
> it on the order of a second or less. I’ve worked on an IPsec
> implementation, but not done a lot of real-world operational use of it; I
> gather that key lifetimes of 86,400 seconds (24 hours) and 3,600 seconds
> (one hour) are common. You could ramp down your QKD performance demands
> that low, if you like, but that seems to severely under-utilize even the
> modest capabilities of existing unentangled QKD systems, and seems
> reasonable for entangled systems.
>
> At the upper end, nobody is likely to turn on one-time pad via QKD until
> you can do a gigabit per second or so, and as you point out existing
> systems beat that by a couple of orders of magnitude.
>
> So the real meta-message of this slide is that QKD offers a set of
> utilization scenarios with increasing security as the QKD performance
> increases.  It gives us a pathway for useful quantum networks: we can point
> to reasonable use cases covering nine or more decimal orders of magnitude
> in performance. Low-performance systems can be useful, and high-performance
> systems more useful.
>
> And of course as you’ve already grasped but left unsaid, the working
> assumption here is that recording encrypted traffic today and decrypting it
> some years from now is an interesting attack, which of course depends on
> your use case. Some people have proposed using QKD e.g. to harden the
> real-time control networks for power plants, but I don’t think that’s a
> good use case; in twenty years, nobody cares that you tweaked the phase
> Monday afternoon and upped the output Tuesday morning. But banking is a
> little stronger case, and diplomatic/military communication stronger still.
>
>
> - You have the three phases "Factoring becomes possible", "AES broken",
> "testing all keys becomes possible". Agree that "Factoring becomes
> possible" will clearly happen as soon as someone build a large enough
> quantum computer.
>
>
> Or somebody finds a flaw in Diffie-Hellman. (“Factoring” includes
> “discrete logarithm” in this context. Hopefully no one will make me justify
> that :-).)
>
> For any symmetric crypto system, if it somehow magically becomes possible
> to test all possible key candidates in a reasonable time, then all
> symmetric crypto is busted. No one I know is suggesting this is possible,
> it’s a strawman hypothetical.
>
> You can go buy boxes that do this today from one of those startups in an
> earlier slide, and deploy them over metro-area networks. It takes a fair
> bit of coin and the usual amount of patience with bleeding-edge tech, but
> it’s possible.
>
> Breaking AES is clearly unfeasible today. Breaking AES-256 will definitely
> always be infeasible with Grover's algorithms and it is unclear if breaking
> AES-128 will ever be practical with quantum computers (the depth of the
> quantum circuit will be very large).
>
>
> Agreed, and fully error-corrected QCs remain a ways off, at best. But I
> reserve the right to change my opinion if someone as smart as Peter Shor or
> Lov Grover comes up with another quantum or classical algorithm that
> presents a plausible attack.
>
>
> - You should add (PQC running on classical computer, e.g. lattice bases) +
> AES to the slide. That's seen as the main way forward in the security
> community.
>
>
> Good point, it’s probably time to update that slide. Other than adding the
> pointer to weakdh.org, this slide hasn’t evolved much in the last several
> years. It’s already a lot for non-specialists to grasp, though, and I don’t
> want to make it too complicated.
>
> —Rod
>
>