otrv4 / otrv4

Off-the-Record Messaging Protocol version 4. -This is a draft- This repository is a mirror of http://bugs.otr.im/otrv4/otrv4

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Brace Key is not post-quantum

sebastianv89 opened this issue · comments

The brace key is not providing post-quantum confidentiality and I think it should not be advertised as such. It only provides protection in case elliptic curve cryptography is broken, but not against quantum cryptanalysis in general.

Although Shor's algorithm requires fewer qubits in order to break Ed448-Goldilocks (compared to breaking 3072-bit DH), the difference is not significant. Assume it takes another thirty years until we have fault-tolerant quantum computers big enough to break Ed448-Goldilocks and another two years beyond that to scale up the computer to break 3072-bit DH. That means that the use case is confidentiality for messages that need to remain secure for another thirty years, but no longer than thirty-two years. The exact timeline may turn out to be different, but the point remains that 3072-bit DH will be broken very shortly after Ed448 once large-scale quantum computers become a reality. The uncertainty around the exact timeline in fact makes the practicality of the brace key even more questionable.

Compare this against the standard solution that mixes both the result of a classical (ECC) key-exchange and the result of a IND-CPA post-quantum KEM (or multiple) in the KDF such that both (all) need to be broken in order to break confidentiality. That solution provides confidentiality for data that needs to remain secure forever, even if quantum computers become a reality.

I think it is misleading to say that the brace key provides any kind of post-quantum security.

This comment applies to

  • ADR5, section Context
  • ADR6, section Consequences
  • otrv4, section Security Properties

I agree that may be optimistic. But maybe less so than you think: your qubit estimate is off.

In order to compute the ECDLP we need 9n+2⌈log2(n)⌉+10 qubits, whereas the regular DLP requires just 2n+2 qubits [https://eprint.iacr.org/2017/598]. Here n is the size of the field, so for ed448 that would be 448 and for dh3072 it would be 3072. Plugging in the numbers reveals that we need 4060 qubits for breaking in Ed448 and 6146 for breaking DH3072. I think that once we get up to quantum computers with thousands of error-corrected qubits, the time it takes to scale 1.5x will really not be that long.

You mention the Postquantum Preshared Keys (PPK), which is indeed a solution that could provide post-quantum confidentiality, but with the very important caveat that the key itself must remain secure, which is very difficult to do securely since you want to share the key between clients. For example say that you simply modify (or even just inspect) the /etc/ipsec.secrets file over an SSH connection: that data has just travelled over a connection that was not post-quantum confidential. In general there is a bootstrapping problem with the PPK solution: how to transfer secret key material from one machine to another without having post-quantum confidential protocols?

Hi, Sebastian and Paul,

Thanks for the comments. I'll try to answer all of this :)

The brace key is not providing post-quantum confidentiality and I think it should not be advertised as such. It only provides protection in case elliptic curve cryptography is broken, but not against quantum cryptanalysis in general.

I completely agree. I think it was a bad choice of wording. The idea is that the ECDH keys will be broken in less time than the DH keys, which provides a little bit of protection. But they are not meant to be quantum-resistant at all. I'll try to clarify this.

I have to read up on the spec, so I don’t know what the brave key is. But for IKE/IPsec where we have a PPK to mix into the PRF/KDF the draft recommends a 256 bit random PPK. But also, the draft assumes DH3072 and ECDH and ed448 would be broken by a quantum computer.

@letoams can you send me the draft?

In order to compute the ECDLP we need 9n+2⌈log2(n)⌉+10 qubits, whereas the regular DLP requires just 2n+2 qubits [https://eprint.iacr.org/2017/598]. Here n is the size of the field, so for ed448 that would be 448 and for dh3072 it would be 3072. Plugging in the numbers reveals that we need 4060 qubits for breaking in Ed448 and 6146 for breaking DH3072. I think that once we get up to quantum computers with thousands of error-corrected qubits, the time it takes to scale 1.5x will really not be that long.

I think this is actually very useful information as people are often confused around PQ. I'll try adding something like this to the ADR.

Yes it is bad. Let's hope we get proper strong postquantum algorithms in the next few years so we do not need PPKs :)

Let's see about that. I'm confident on the next years around this :)

Thanks!

Thanks @letoams !

As @claucece mentioned, the brace key is not for quantum resistance - but a bit of time insurance in case of two alternative scenarios - if it does take a long time to get to 1.5x the qubits - or if a new improved attack on ECC comes out. However, I agree that the 1.5x is probably not that long. Maybe we should double back with Ian about it.

At this point we have no real urge to mix in a post-quantum KEM for the reasons outlined in the ADRs around why we don't have post-quantum algorithms in v4. Hopefully the situation around what algorithms to use have settled down a bit when it's time to do v5, and at that point we can revisit.

Time insurance (I like the term) makes sense when we are talking about authentication, because we want some time to switch over to newer algorithms once we suspect that there are adversaries with improved capabilities for cryptanalysis. For confidentiality however I do not think time insurance makes sense. When I want something to remain secret, I don't care whether my secret leaks thirty years from now or thirty-two years.

I am happy with the way @claucece reworded this in her commit, so I consider this issue resolved.