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

71–80 of 81 posts

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

#71

Post by Rebelgecko »

xhkkffbf wrote: post #64
NovemberWhiskey wrote: post #56

Earlier quoted context omitted.

> I'm not sure I buy the Global Risk Institute chart. I get that they need to motivate adoption, but practical cryptanalytic work with quantum computers seems unpromising right now. Yeah; that doesn't look right to me either. Perhaps "cryptographically relevant" has some unusual meaning (parity with conventional computing?). Otherwise, the consensus view is that there's, pessimistically, a 4% probability of a total b…

Who came to this consensus? I'm not aware that the quantum machines have been able to do much beyond, say, factoring 21.

I think they were factoring 21 a decade or so ago. Now the record is at least 261,980,999,226,229. Although my understanding is that this # was somewhat cherry picked and the algorithm they used (not shor's) worked well on this 48 bit number but wouldn't scale as well as Schor's algo to sizes that are cryptographically meaningful

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

#72

Post by tsimionescu »

n4r9 wrote: post #61
upofadown wrote: post #55

Earlier quoted context omitted.

A non-linear advance probably wouldn't involve Shor's algorithm. As what happened with AI algorithms. What we call post quantum cryptography is really post Shor's cryptography.

The difference is that we know Shor's algorithm will work once you solve certain engineering problems. As I understand it even the theoretical side of AI was always shooting in the dark.

I don't think it's really fair to call these engineering problems. Creating a working quantum computer is at the bleeding edge of experimental physics. Sure, the theoretical physics behind a working QC is somewhat understood, but there are no successful experiments in the area.

Even the theory is somewhat debatable, as creating a working QC pushes close to the boundaries of the measurement problem.

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

#73

Post by NovemberWhiskey »

ls612 wrote: post #66
NovemberWhiskey wrote: post #57

Earlier quoted context omitted.

> Besides encrypting your user data at rest using these post-quantum cryptography algo. If you're encrypting data at rest, just keep using an appropriate mode of AES (or ChaCha20 or whatever+) and exercising good key management practices. Quantum computing is largely irrelevant to conventional symmetric ciphers. + for tightly constrained values of 'whatever'

QC will break AES 128 and reduce the margin of security for AES 256 is my understanding.

QC is worth a one bit of reduction in security strength for AES.

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

#74

Post by Tarq0n »

xhkkffbf wrote: post #65
Tarq0n wrote: post #51

Earlier quoted context omitted.

It also depends on what your personal requirements for forward secrecy are. As a major platform operator Google should aim somewhere towards the top of that distribution.

Why does Google need long-term forward secrecy? They may encrypt my sessions with keys, but most of their data is the huge index of the public web which is, by definition, public. I suppose they dabble in things like health records, but it seems like most of what they store and forward are public.

Google operates among other things an office suite, a cloud platform, the largest repository of location services data in the world and an IoT health/lifestyle devices company.

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

#75

Post by xhkkffbf »

Tarq0n wrote: post #74
xhkkffbf wrote: post #65

Earlier quoted context omitted.

Why does Google need long-term forward secrecy? They may encrypt my sessions with keys, but most of their data is the huge index of the public web which is, by definition, public. I suppose they dabble in things like health records, but it seems like most of what they store and forward are public.

Google operates among other things an office suite, a cloud platform, the largest repository of location services data in the world and an IoT health/lifestyle devices company.

And do they encrypt any of those details aside from while the data is in transit? My impression is that they don't.

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

#76

Post by ogurechny »

xhkkffbf wrote: post #75
Tarq0n wrote: post #74

Earlier quoted context omitted.

Google operates among other things an office suite, a cloud platform, the largest repository of location services data in the world and an IoT health/lifestyle devices company.

And do they encrypt any of those details aside from while the data is in transit? My impression is that they don't.

Any big company has numerous data access restrictions. Some of them are obligatory and external, or required for certification. Even basic HDD/SSD decommission and transfer between projects strongly implies that old data was not stored as clear text.

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

#77

Post by ls612 »

NovemberWhiskey wrote: post #73
ls612 wrote: post #66

Earlier quoted context omitted.

QC will break AES 128 and reduce the margin of security for AES 256 is my understanding.

QC is worth a one bit of reduction in security strength for AES.

No it’s worth a 1/2 reduction in the number of bits. So 256 becomes effectively 128 bit encryption. Idk though if the solution could be as simple as creating “AES 512”.

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

#78

Post by Asraelite »

SamuelAdams wrote: post #53
thadt wrote: 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…

> It might be a long time (if ever) before cryptographically relevant quantum computers show up Don’t be so sure. From the article, Google seems to believe quantum computers will arrive in the next 10 years.

"in as soon as a decade".

They think it's possible. I doubt anyone there thinks it's certain or even has a high probability.

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

#79

Post by remus »

xhkkffbf wrote: post #75
Tarq0n wrote: post #74

Earlier quoted context omitted.

Google operates among other things an office suite, a cloud platform, the largest repository of location services data in the world and an IoT health/lifestyle devices company.

And do they encrypt any of those details aside from while the data is in transit? My impression is that they don't.

Im pretty sure they encrypt anything remotely sensitive at rest. A quick google found sources for this for cloud [1] and drive [2].

[1] https://cloud.google.com/docs/security/encryption/default-en...

[2] https://support.google.com/drive/answer/10375054?hl=en-GB

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

#80

Post by literallyroy »

nimih wrote: post #38
nine_k wrote: 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.

We are doing this and it works pretty great across a bunch of microservices.

A user makes a call into a gateway, which talks to the identity service to get a JWT with info about who the user is. Now the gateway passes the call on to the microservice being referenced and it gets the users basic access info with no extra calls, and better it can call any other internal service and continue to pass along the token.

Post reply on HN