Live data from Hacker News

Google's threat model for post-quantum cryptography

bughunters.google.com

41–50 of 81 posts

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

#41
A counter-point that perhaps everyone is taking PQ a bit too seriously [1].

Personally, it seems reasonable to at least spend some effort preparing for it, given the rather long lead time required to develop, study and stress the constructions needed. It might be a long time (if ever) before cryptographically relevant quantum computers show up, but if they do, we'll be glad we had a decade or two to get ready. The alternative of scrambling at the last minute while everything gets cracked seems unenviable.

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto...

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

#42
post #38
post #28

Earlier quoted context omitted.

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.

Istio with JWT seems petty common.

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

#43
post #42
post #38

Earlier quoted context omitted.

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.

Istio with JWT seems petty common.

True, but I think doing something just because a lot of other people are doing it doesn’t make it good or correct.

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

#44
post #39

Just from reading this it's a bit unclear to me why they recommend only SPHINCS+ for "Firmware Signatures", while for "Software Signatures" they recommend Dilithium3+hybrid or SPHINCS+. Is SPHINCS+ more lightweight?

SPHINX+ is actually slower (which does not matter much as firmware signatures generation or verification are not time critical) but it is the most conservative choice available (avoids only relying on the security of lattices for signatures), which is very valuable for firmware that cannot be easily updated if a security issue arises with lattice-based signatures. It also offers the smallest public key size, which may help for devices with limited storage.

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

#45
post #42

Earlier quoted context omitted.

Istio with JWT seems petty common.

True, but I think doing something just because a lot of other people are doing it doesn’t make it good or correct.

Well, the question was about how often is it used, not how well it serves the purpose. So I'd say pretty often.

Having a data storage accessible for every service that needs authentication and authorization (and ideally every service needs at least authentication) is non trivial in distributed enterprise environment. To have a stateful token, you need to have a distributed scalable storage, unless you have only one instance. You need to be able to connect to it, hence distribute and manage database password. Anything symmetric requires a more sophisticated secret management.

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

#47

Earlier quoted context omitted.

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.

Well, there are PQC (public key) signature schemes based on hash functions, but they all have large signatures (in the multi-kB range) and other drawbacks (eg being stateful).

Moving to a MAC is also not a crazy idea in a lot of deployments. You can horizontally scale an internal MAC validation service. I believe Facebook use MAC-based tokens internally (CATs).

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

#48

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?

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

Well, SQIsign signatures are about the same size (204 bytes) than RSA-2048 (256 bytes). So ok, but most people who care about size on the wire have moved to EC sigs, which are much smaller (64 bytes). And “fast to verify” is not really true: 50ms is not fast — both RSA and Ed25519 signature verification is <0.1ms.

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

#49
post #41

A counter-point that perhaps everyone is taking PQ a bit too seriously [1]. Personally, it seems reasonable to at least spend some effort preparing for it, given the rather long lead time required to develop, study and stress the constructions needed. It might be a long time (if ever) before cryptographically relevant quantum computers show up, but if they do, we'll be glad we had a decade or two to get ready. The al…

The risk is non-linear advances

That's what everybody said about AI, then sudden advances ~2013 led to the situation today.

Post reply on HN