Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's threat model for post-quantum cryptography

bughunters.google.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Google's threat model for post-quantum cryptography

#31

Post by wbl »

dist-epoch wrote: post #15
tptacek wrote: post #5

Stateless tokens come with independent security concerns, and moving towards stateful tokens is prudent just to ensure more robust systems. [...] Our main recommendation is to use stateful tokens where possible, given their additional security benefits. This is smart. PQC schemes often add too much overhead for interoperable cookie sizes. Instead of trying to cram a PQC signature into a cookie, just stop using the st…

Is there any insight why there is no PQC signature with a short signature? Is it just us failing to find one, or something more fundamental prevents a quantum resistant short signature like?

There is! It just takes milliseconds to verify and has questionable security

Re: Google's threat model for post-quantum cryptography

#32

Post by bee_rider »

JanisErdmanis wrote: post #12

The threat estimate for a quantum computer that breaks cryptography shall be based on currently available data and the understanding that only the Schor algorithm is known to provide exponential speedup for factorisation. Let’s give IBM credit for attempting to factor in the number 35 in 2022, although they failed there [1]. Before that, the successful factorisation happened for the number 21 in 2012 [2] and the firs…

I think they must not be planning on the trend being linear. Maybe we’re at the linear looking beginning of a sigmoid.

It seems like a reasonable bet on their part, in the sense that Google has a lot of money to play with. Even if it is unlikely that it takes off, behind hit by quantum attacks would be pretty bad for them, so maybe they see it as insurance against an unlikely but catastrophic event.

Re: Google's threat model for post-quantum cryptography

#33

Post by maple3142 »

dist-epoch wrote: post #15
tptacek wrote: post #5

Stateless tokens come with independent security concerns, and moving towards stateful tokens is prudent just to ensure more robust systems. [...] Our main recommendation is to use stateful tokens where possible, given their additional security benefits. This is smart. PQC schemes often add too much overhead for interoperable cookie sizes. Instead of trying to cram a PQC signature into a cookie, just stop using the st…

Is there any insight why there is no PQC signature with a short signature? Is it just us failing to find one, or something more fundamental prevents a quantum resistant short signature like?

SQIsign is relatively small and fast to verify, but it is pretty slow to sign.

Re: Google's threat model for post-quantum cryptography

#34

Post by 4death4 »

bawolff wrote: post #13
xyst wrote: post #11

Besides encrypting your user data at rest using these post-quantum cryptography algo. What can be done from a design point of view to make it as hard as possible to deter attackers? Would it make sense to segregate different types of data into other dbs rather than as a separate table? “Name DB” “Account DB” “Address DB” An attacker would need to have advanced knowledge of the app backend to know you have to snag bot…

This doesn't make sense: - i think encryption at rest would probably just use symmeyric encryption which is unaffected by shor - how does the attacker get into your network in this scenario. Stuff encrypted at rest by definition is not flying around the network. - what sort of scenario would be involved where the attacker knows how to get one db but not the others? The hard part is figuring out the first db > Drawbac…

Minor nit, symmetric encryption is “impacted” by QC, see Grover’s algorithm. The speed up isn’t as fast, though.

Re: Google's threat model for post-quantum cryptography

#36

Post by bawolff »

4death4 wrote: post #34
bawolff wrote: post #13

Earlier quoted context omitted.

This doesn't make sense: - i think encryption at rest would probably just use symmeyric encryption which is unaffected by shor - how does the attacker get into your network in this scenario. Stuff encrypted at rest by definition is not flying around the network. - what sort of scenario would be involved where the attacker knows how to get one db but not the others? The hard part is figuring out the first db > Drawbac…

Minor nit, symmetric encryption is “impacted” by QC, see Grover’s algorithm. The speed up isn’t as fast, though.

it is also trivial to work around by just doubling the key length. But even without that the speed up is slow enough that we will be well within the quantum age before this matters. The article talks about this a bit.

Re: Google's threat model for post-quantum cryptography

#37

Post by bawolff »

dist-epoch wrote: post #15
tptacek wrote: post #5

Stateless tokens come with independent security concerns, and moving towards stateful tokens is prudent just to ensure more robust systems. [...] Our main recommendation is to use stateful tokens where possible, given their additional security benefits. This is smart. PQC schemes often add too much overhead for interoperable cookie sizes. Instead of trying to cram a PQC signature into a cookie, just stop using the st…

Is there any insight why there is no PQC signature with a short signature? Is it just us failing to find one, or something more fundamental prevents a quantum resistant short signature like?

Keep in mind it took us quite a while to move to short (ECC based) public key schemes for classical crypto. Although some of that is for non-technical reasons.

Re: Google's threat model for post-quantum cryptography

#38

Post by nimih »

nine_k wrote: post #28
esprehn wrote: post #25

Earlier quoted context omitted.

The header dictionary for http2 makes large headers like cookies less of an issue: https://blog.cloudflare.com/hpack-the-silent-killer-feature-... Which means it's only sent once per connection.

This is good for browsers which do a ton of requests to the same resource. It's less useful for service-oriented architecture where services would more often talk to other services through an LB, often contacting different nodes.

Are you regularly using stateless, asymmetrically-encrypted tokens during service-to-service communication? That strikes me as a rather odd architecture decision, but maybe there's something I'm missing.

Re: Google's threat model for post-quantum cryptography

#40

Post by fsh »

smburdick wrote: post #16
JanisErdmanis wrote: post #12

The threat estimate for a quantum computer that breaks cryptography shall be based on currently available data and the understanding that only the Schor algorithm is known to provide exponential speedup for factorisation. Let’s give IBM credit for attempting to factor in the number 35 in 2022, although they failed there [1]. Before that, the successful factorisation happened for the number 21 in 2012 [2] and the firs…

From [1]: > We implemented the algorithm on IBM quantum processors using only 5 qubits Last December, a team based out of Harvard demonstrated the ability to scale up to 48 logical qubits: https://arxiv.org/abs/2312.03982 It has been shown that, to factor an integer with n bits, Shor's algorithm requires ~2n logical qubits: https://arxiv.org/pdf/quant-ph/0205095.pdf

Running Shor's algorithm requires essentially error-free logical qubits. Not a single logical qubit of that quality has ever been demonstrated. The Harvard results are impressive, but their logical qubits are worse than some physical qubits.
Post reply on HN