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

21–30 of 81 posts

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

#21

Post by GuB-42 »

dvh wrote: post #8

This may be a naive question but why not go back to Vernam? Storage is cheap.

In addition to the usual argument about the impracticality of the one time pad. There is also that it is symmetric cryptography (the one time pad is a shared secret).

Symmetric algorithms (AES-256 in particular) are generally considered to be quantum resistant. Here is what written about it in the article.

> Symmetric cryptography, using a single secret key to encrypt and authenticate data: In our current understanding, symmetric cryptography is not impacted by quantum computers for all practical purposes. Grover's algorithm could be used as an attack here, but is currently considered infeasible for even medium-term quantum computers. (See "Reassessing Grover's Algorithm, 2017")

The algorithms most affected by quantum cryptanalysis are public key (asymmetrical) algorithms, because we already have effective quantum algorithms against them (Shor's in particular). We are not even close to having the computer though.

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

#22

Post by adtac »

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…

Even if the cookie size limit was 8192 bytes instead of 4096, I think it's insane to include a several KB signature on every request over the network (literally worth multiple packets). It's not a big deal if the payload is a large media file, but JWTs are most commonly used in the kind of API requests where the body is often empty or something tiny like {"success": true}. It'd be a shame to undo all the wins from things like smaller TLS handshakes using ECDSA (more of a pleasant side effect, but still).

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

#23

Post by agl »

comex wrote: post #14

> There are several alternatives to simply replacing classical signatures with quantum-safe signatures, which could address the performance issues when it comes to PKI. We are currently looking to experiment in this space to gather data for more solid recommendations, which we will share in a future blog post. Does anyone know what those alternatives might be? Some way to collapse a chain of signatures into one? Long…

https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-t...

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

#24

Post by adastra22 »

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?

I’m confused because there are such things. What you want here is authentication, and there are hashing modes which provide that.

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

#25

Post by esprehn »

adtac wrote: post #22
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…

Even if the cookie size limit was 8192 bytes instead of 4096, I think it's insane to include a several KB signature on every request over the network (literally worth multiple packets). It's not a big deal if the payload is a large media file, but JWTs are most commonly used in the kind of API requests where the body is often empty or something tiny like {"success": true}. It'd be a shame to undo all the wins from th…

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.

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

#26

Post by some_furry »

adastra22 wrote: post #24
dist-epoch wrote: post #15

Earlier quoted context omitted.

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?

I’m confused because there are such things. What you want here is authentication, and there are hashing modes which provide that.

They specifically asked about PQC signatures, not MACs.

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

#28

Post by nine_k »

esprehn wrote: post #25
adtac wrote: post #22

Earlier quoted context omitted.

Even if the cookie size limit was 8192 bytes instead of 4096, I think it's insane to include a several KB signature on every request over the network (literally worth multiple packets). It's not a big deal if the payload is a large media file, but JWTs are most commonly used in the kind of API requests where the body is often empty or something tiny like {"success": true}. It'd be a shame to undo all the wins from th…

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.

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

#29

Post by _tk_ »

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…

They mention they are working on their own QC. In corporate logic, using a third party projection to make a statement about where you are headed seems absolutely legit to me.

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

#30

Post by nine_k »

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…

If I were an adversary possessing a (quantum) code-breaking device, who can break into your infra that uses a (pre-quantum) encryption for authorization, I probably would attach a debugger to your worker process, and find out about all your databases, and maybe hijacked a live connection to one.

If I only could get access to nothing but one database, and every table / segment of it were encrypted differently, it would likely take as much effort to break into each of them, as if they were "physically separate" databases.

Post reply on HN