7 ms·
Advancing Our Bet on Asymmetric Cryptography
- throw_pm23 2y ago[flagged]
- joshuaissac 2y agoIt works without JavaScript for me. Maybe your ad-blocker or uMatrix configuration has a rule that is blocking something unintentionally.
- stogot 2y agoThe mobile Firefox Focus tracker blocker basically breaks every Google blog for tracking, not for ads. So it’s blank for me as well
- GoblinSlayer 2y agoText is in noscript tag, but noscript tag is dangerous due to massive abuse by everyone including google. The page has another noscript tag with doubleclick tracker inside.
- deleted 2y ago[deleted]
- ai_what 2y agohttps://archive.is/kdlWh https://archive.is/kdlWh
- aborsy 2y ago[flagged]
- meindnoch 2y agoAsymmetric cryptography
- some_furry 2y agoMore specifically, post-quantum cryptography.
- M95D 2y agoWikipedia: > NIST calls its draft standard Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). However, at least for Kyber512, there are claims that NIST's security calculations were amiss.
- aborsy 2y agoThat’s a “bet” on something that everyone is sure about, so not much of a bet!
- lupire 2y agoMost people don't believe a cryptographically-relevant quantum computer will ever exist as an real world engineering artifact. If NSA believed it were possible, they would not publicly promote research on post-quantum cryptography, the would crack quantum cryptography.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- mrbluecoat 2y ago[flagged]
- warkdarrior 2y agoThis seems overengineered. There must be a simpler way to monitor you than this multi-certificate boondoggle, especially that Google controls the browser endpoint.
- gruez 2y ago>This conflict, in turn, limits [our ability to monitor you] ... We propose to solve this by moving to a multi-certificate deployment model, where servers may be provisioned with multiple certificates [including those Google controls], and automatically send the correct one [i.e. the one Google controls] to each client. How did you go from "chromium wants servers to support multiple certificates" to "chromium wants servers to support multiple certificates so they can put in their own certificates and MITM you"? Don't cloudflare and other CDNs already have the ability to MITM people given that they control the certificates? Why does google need this elaborate conspiracy to MITM people?
- mrbluecoat 2y agoAdmittedly it's a stretch, but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS." https://www.chromium.org/Home/chromium-security/root-ca-policy/ https://www.chromium.org/Home/chromium-security/root-ca-poli... I also find it hypocritical that Google wants a multi-certificate architecture when they won't allow sysadmins their own certificate: https://issuetracker.google.com/issues/168169729?pli=1 https://issuetracker.google.com/issues/168169729?pli=1
- gruez 2y ago>but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS." It's probably a downstream effect from iOS not allowing third party rendering engines on ios, and the API for safari webview doesn't allow developers to swap out the TLS stack. >I also find it hypocritical that Google wants a multi-certificate architecture when they won't allow sysadmins their own certificate: https://issuetracker.google.com/issues/168169729?pli=1 https://issuetracker.google.com/issues/168169729?pli=1 It really isn't. The linked issue seems to revolve around allowing root CAs to be added without user involvement, which presents privacy/security issues. Meanwhile being able to support multi-certificate in this context is motivated by being able to use newer cryptographic algorithms while still being able to support legacy devices, eg. presenting ECDSA certificate to modern devices but presenting an RSA certificate to decades old IOT devices that only support RSA. I don't see how that's contradictory with "we don't want to allow installing CAs behind users' backs because it might be abused to spy on them".
- quaunaut 2y agoTo tl;dr for people: - As we've known for years, cryptographically-relevant quantum computers(CRQC) likely could wreck digital security pretty massively - For HTTPS, 2 out of its 3 uses of cryptography are vulnerable to CRQC - The currently accepted algorithms that fix these vulnerabilities transmit 30+ times the data of current solutions, which for more unreliable network conditions(like mobile) can introduce latency by as much as 40% - Because attackers could store data now and decrypt it later with a CRQC, some applications need to deploy a solution now, so Chromium has enabled Kyber(aka ML-KEM) for those willing to accept that cost - However, other algorithms are being worked on to reduce that data size, but server operators for your applications at the moment can generally only use one certificate, which older clients like smart TVs, kiosks, etc are unlikely to support - So they're advocating for "trust anchor negotiation" by letting clients and servers negotiate on what certificate to use, allowing for servers to allow multiple at the same time Honestly really impressively written article. I've understood the risk that a cryptographically-relevant quantum computer would pose for years, but I didn't really know/understand what was being done about it, or the current state of things.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- IncreasePosts 2y ago[flagged]
- deleted 2y ago[deleted]
- k__ 2y agoAs far as I understood it, the tech is already there (Lattice-based algorithms, etc.) but nobody has bothered to deploy it yet. Probably a similar issue as IPv6.
- mcpherrinm 2y agoThe tech is only being developed and standardized now. Some of the post-quantum algorithms (like SIKE) have fallen. NIST standardization is ongoing. "nobody has bothered" ignores the fact that this is probably the biggest thing going on in cryptography right now. We're in the comments on a post about how Google is working towards adding support! And it's not really ready yet, unfortunately: The current post-quantum signature algorithms are too big for our current TLS/TCP/MTU packet sizes, and are going to be a big performance hit. One of the above post's authors has previously written about the size problem on his own blog: https://dadrian.io/blog/posts/pqc-signatures-2024/ https://dadrian.io/blog/posts/pqc-signatures-2024/ - with comments at https://news.ycombinator.com/item?id=39796349 https://news.ycombinator.com/item?id=39796349
- ysofunny 2y agoso any post-quantum crypto requires packets bigger than TCP can handle in a single message? I just super cynically see google pushing for quic and their other post-tcp visions for an internet even more theirs than it already is
- vlovich123 2y agoNo that would be silly - TCP handles “infinite” length streams. The problem is that there’s so much extra data for the cryptographic handshake that latency of establishing the connection is meaningfully higher by a lot and performance degrades by a meaningful amount. That’s all. I don’t know why OP brought in MTU and packet sizes since that doesn’t really apply here. The most you could say is that the size exceeds the TCP window requiring an explicit ack but that’s unlikely (windows are quite big) and everything I’ve read only talked about the latency of the handshake being caused by the much larger data exchange needed (ie if TLS handshake requires 32 bytes each way, Kyber and friends need to send 1kib each way [1]) [1] https://blog.cloudflare.com/post-quantum-for-all/ https://blog.cloudflare.com/post-quantum-for-all/
- thadt 2y agoInteresting. It does seem that being more agile in PKI deployment is going to be a requirement in the next few years as we grapple with rolling out a potentially interesting variety of PQ signatures and hybrids. Especially considering exploding PQ signature and key sizes, this looks increasingly like a data synchronization problem between the server and clients. I wonder if we could kill two birds with one stone by using trust expressions consisting of a set of certificate indexes against a trust store database, instead of trust store versions and exclusion labels. In that model, a trust store is just a centrally managed list where each certificate is assigned a unique 64-bit index. For example, a client says "I use trust store database XYZ with certificate indexes: <ordered, integer compressed 64-bit index list, maybe a couple hundred bytes>". The server constructs (or pulls a cached copy of) a trust chain from one of the listed roots and sends it to the client. Intermediate certificates may also be stored in the trust store database - and cached on the client. In subsequent requests, the client may include those intermediate indexes in their request, allowing the server to respond with a shorter chain. Clients with an old, long trust chain might have a long first exchange, but after caching intermediates can have a much faster/shorter negotiation. As certificates expire, they are removed from both the trust store database, as well as the client's cache - naturally moving the 'working window' of certificates forward over time. This shifts a bit of work on the server, but dramatically reduce complexity on the client. The client just states which certificates it has and what algorithms it supports, and the onus is placed on the server to return the "shortest" chain that the client can use as a proof.
- rezonant 2y agoI'm far from being versed enough here, but from an adversarial standpoint, is having the client offer up the trust stores and certificate IDs it has going to increase the server's knowledge of aspects of the client we don't want it to know? IE could this contribute to fingerprinting or help to understand the browsing history of the device?
- thadt 2y agoYep. If the client gives up its full list of currently cached intermediate certificates it certainly reveals information about its connection history. Clients would probably need to use per-site certificate caching. But in general your point about fingerprinting is well made. The more negotiation that happens between the client and server, the more data that is available for client fingerprinting and tracking from the server side.
- chrisdinn 2y agoIs ”advancing our amazing bet” a nod to the Google Fiber turndown?
- deleted 2y ago[deleted]
- nekoashide 2y agoThis has been causing a number of issues with proxys, we use nginx and we have started to see problems with chrome users and handshakes not working properly.
- BodyCulture 2y agoIs there an issue tracking entry anywhere for this?
- dadrian 2y agoBottom of https://tldr.fail https://tldr.fail
- upofadown 2y agoIf this lowers performance, can we just turn it off and forget about it?
- deleted 2y ago[deleted]
- er4hn 2y agoOne perpetual source of concern that I have is how will this work in practice? NIST has not standardized algorithms as of yet. NSA has come out in opposition of hybrid schemes (note that NSA is also a big fan of CsfC, which uses entirely seperate dual layers of crypto, which could be how they would have a hybrid scheme - one layer classical, one layer pqc. Will they? I ahve no clue). But this protocol is still a draft. OpenSSH has chosen their own algorithm that afaik was on the NIST shortlist for PQC but not a final candidate and incorporated it in OpenSSH. That's not standardized either. Given that Govt (which mandates encryption requirements via blunt tools like saying they will only purchase things that meet their requirements) and Industry are going two ways, and industry is doing whatever they think best without waiting for standardization, it feels like this is going to be a source of headaches to support properly in the future due to the diversity of schemes. I am actually in favor of what Google / OpenSSH are doing, enabling new things shouldn't be breaking stuff, and should just be a net positive in their own bubbles, but the govt opposition and foot dragging makes this harder.
- tptacek 2y agoEverybody is going to use hybrid schemes for the foreseeable future.
- dadrian 2y agoUnlikely that signatures will ever be hybrid. Fairly likely we move off of hybrid for key exchange once NIST finishes standardization.
- thadt 2y agoGeez, turbolaser X-Wing before it even gets in the air. Can y'all just give us a SCW death-match debate on this? Jokes aside, it would be interesting to have your optimistic take on the current PQ security trajectory. Do you think that it has proven comparably secure to ECC? Or just that by the time PQ primitives are ready to be rolled out they'll be load bearing enough that it is better to use them solo rather than the added overhead/complexity of a hybrid?
- tedunangst 2y agoDoubling down on my bet nobody reading this will live to see a quantum computer that breaks year 2000 era crypto.
- sebzim4500 2y agoIs there a way to put money on this? I'd be willing to put down a fair amount against your prediction.
- wcoenen 2y agoIf they win the bet against you, you'll both be dead by definition of the bet. Therefore the bet doesn't make sense and shouldn't be taken seriously.
- im_anon_on_hn 2y agoIt could go to the estate.
- tbrownaw 2y agoSomething like https://longbets.org/ https://longbets.org/ maybe? The funds get held by a third party, and go to the winner's choice of charity rather than to the winner.
- janalsncm 2y agoEncrypt a file with “2000s era cryptography” (not too sure what that would be). The file contains instructions on how to unlock a sum of money.
- sebzim4500 2y agoOk, but how do I make money from that?
- xhkkffbf 2y agoYou could bet in Bitcoin. If the quantum computer doesn't exist, one person gets it. If the quantum computer appears that can break the Bitcoin digital signatures, well, then the Bitcoin is worthless.
- shaftway 2y agoInside Google "Advancing our bet" is a euphemism for shutting down (hat tip to Fiber). I'm deeply surprised that an article came out with that title that is actually true, given how negatively that phrase is seen.
- Nition 2y agoI remember there was a great 'translation' of that fibre post on Hacker News at the time: https://news.ycombinator.com/item?id=12793033 https://news.ycombinator.com/item?id=12793033
- dadrian 2y agoIt's a joke, because it's about migrating off of pre-quantum asymmetric cryptography.
- deleted 2y ago[deleted]
- wiktor-k 2y agoHmm... this is about PQ cryptography while I was expecting a status update of Ed25519 in WebCrypto which, sadly, is still available only via experimental platform flag: https://caniuse.com/mdn-api_subtlecrypto_verify_ed25519 https://caniuse.com/mdn-api_subtlecrypto_verify_ed25519
- xvector 2y agoThis is a really well written article.
- camgunz 2y agoI just finished the Security Cryptography Whatever episode [0] about this and when Eric Rescorla is going on about how they almost threw the Web PKI overboard for a blockchain but it was too slow I was like, "just use a layer 2 like Lightning! It's fast, like Lightning!" But then they described SCTs and I was like, "well OK, way worse name, but they got there" [0]: https://securitycryptographywhatever.com/2024/05/25/ekr/ https://securitycryptographywhatever.com/2024/05/25/ekr/