I think you're describing the models from a year ago. Most of the improvements in capability since then (and the improvements have been really large) are directly due to changes that have the AI model talk to itself to better reason out its response before providing it, and one of the results of that is that most of the time they absolutely can explain why they did what they did. There are exceptions, but they are the exception, not the rule.

It's interesting to compare this with humans. Humans generally can give you an explanation for why they did what they did, but research has demonstrated pretty conclusively that a large majority of the time those explanations are made up after the fact, they're actually post-hoc justifications for decisions that were made in some subconscious process. Researchers have demonstrated that people are just as good at coming up with explanations for decisions they didn't make as for decisions they did! The bottom line is that people can't really provide useful insights on why they did what they did, they're just really good at inventing post-hoc rationales.

If you're asserting that Greg Kroah-Hartman can't code worth a damn, you might want to find out who he is and think again.

And the law of large numbers. Statistically, there will but patch clusters, the same way there are clusters of every other random-ish event. The fact that one happens to occur right after Microsoft promises a commitment to predictable patch schedules means not just nothing the but opposite. Any commitment to doing better means that they recognize they haven't been doing well enough, and obviously it's not possible to do significantly better immediately; changing processes takes time, and observing the effects of those changes takes even longer.

So, no, this cluster of patches doesn't tell us anything in particular beyond what we already knew: That emergency patches are relatively common.

Yes, but... I think you're confusing some things. We're talking about AES, which is a symmetric encryption algorithm, not asymmetric.

Of course, no cryptographic construction has been "proven" secure, in the sense that mathematicians use the word "prove", not symmetric or asymmetric. Asymmetric schemes have an additional challenge, though, which is they have to have some sort of "trapdoor function" that mathematically relates a public key and a private key, and the public key has to be published to the attacker. Classical asymmetric cryptography is built by finding a hard math problem and building a scheme around it -- which means that a solution to the math problem breaks the algorithm.

Symmetric systems have it a bit easier, because the attacker doesn't get to see any part of the key or anything related to the key other than plaintext and corresponding ciphertext (though the standard bar is to assume the attacker has an oracle that allows them to get plaintext of arbitrary ciphertexts, i.e. the Adaptive Chosen Ciphertext attack, IND-CCA2). And the structure of symmetric ciphers isn't usually built around a specific math problem. Instead, they tend to just mangle the input in extremely complex ways. It's hard to model these mathematically, which makes attacking them with math hard.

In both cases, we are unable to prove that they're secure. When I started working on cryptography, the only basis for trust in algorithms was that they'd stood up to scrutiny for a long period of time. That was it. Over the last 20 years or so, we've gotten more rigorous, and "security proofs" are basically required for anyone to take your algorithm seriously today... but they aren't quite like "proofs" in the usual sense. They're more precisely called "reductions". They're mathematically-rigorous proofs that the security of the algorithm (or protocol) is reducible to a small set of assumptions -- but we have to assume those, because we can't prove them.

For most asymmetric schemes, the primary underlying assumption is that the mathematical problem at the heart of the scheme is "hard". Interestingly, there is one family of asymmetric signature schemes for which this is not true. SLH-DSA, one of the post-quantum algorithms recently standardized by NIST, provably reduces to one assumption: That the hash algorithm used is secure, meaning that it has both second pre-image resistance plus a more advanced form of second pre-image resistance. Collision resistance isn't even required! This is striking because we actually have quite a lot of confidence in our secure hash algorithms. Secure hash algorithms are among the easiest to create because all you need is a one-way function with some additional properties. And we've been studying hash functions very hard, for quite a long time, and understand them pretty well.

This means that one of our "new" post-quantum asymmetric algorithms is probably the very strongest we have, not only less likely to be broken than our other asymmetric algorithms, but less likely to be broken than our symmetric algorithms. If it were broken, it would be because someone broke SHA-256 (which, BTW, would break enormous swaths of modern cryptography; it's extremely hard to find a cryptographic security protocol that doesn't use SHA-256 somewhere), and unless that same research result somehow broke all secure hash functions, we could trivially repair SLH-DSA simply by swapping out the broken hash function for a secure one.

This is an entirely different model from the way we looked at cryptography early in my career. SLH-DSA doesn't have decades of use and attack research behind it. Oh, the basic concept of hash-based signatures dates back to the late 70s, but the crucial innovations that make SPHINCS and its descendants workable are barely a decade old! BUT we have a rigorous and carefully peer-reviewed security proof that demonstrates with absolute mathematical rigor that SLH-DSA is secure iff the hash function used in it is secure.

So... a relative newcomer is more trustworthy than the algorithms we've used for decades, precisely because we no longer rely on "hasn't been broken so far" as our only evidence of security.

As for AES, the subject of the discussion above, there is no security proof for AES. There's nothing to reduce it to. There are proofs that it is secure against specific attack techniques (linear cryptanalysis and differential cryptanalysis) that were able to defeat other block ciphers, but those proofs only prove security against those specific attacks, not other attacks that are not yet known. So for AES we really do rely on the fact that it has withstood 20+ years of focused cryptanalysis, and that no one has managed to find an attack that significantly weakens it. That could change at any time, with or without quantum computers.

SLH-DSA, however, is one that very well may be secure forever, against both classical and quantum attacks. The security proof doesn't even care about classical vs quantum, it just proves that any successful attack, no matter how it's performed, provides a way to break the underlying hash function. Therefore, if the hash function is secure, SLH-DSA is secure. It's an incredibly powerful proof, like many proofs by contradiction.

I don't like ads either, but I do like that they (at least for now) have a paid tier with no ads. If there was an option to use google services at some paid tier, without being part of their ad network, I'd probably pay it. But there isn't and llm is as good as search these days (in many cases anyways) so I'm happy to jump ship. Piss off, google.

Trump in his first term was willing to go all-in on human spaceflight to mars...until he realized he couldn't get it done before the end of his term. Trump has always been interested in space stuff...but only if it's achievable within his term. This seems like a play to keep contractors employed and skills sharp until the next administration is seated, which will hopefully be willing to invest in goals longer than 4 years.

Unfortunately everyone picked an opinion two years ago, when AI was genuinely garbage beyond some basic bash scripts or a top 1000 bug/question on stack exchange (which mostly overlap). AI started getting really good in Dec '24, particularly spring '25 and by August 2025 even the $20/mo tier of chatgpt was starting to get legit as OpenAI started to try catching up with (now market leader) Anthropic and their blessed claude code. The 4.5/4.6 models released this year are nothing short of incredible, and the Qwen 3.5 series of models are right behind the state of the art models. Google is doing some stuff too but I'm kind of done giving them my money.
 
In 2-3 years we'll have found all 20,000 top reasons LLMs hallucinate things and solved for 95% of them
 
Creatives rallied against LLMs but as has been proven, nobody actually cares about making funny pictures of , they just want to know that they can.

An exception is the Zeropatch technique where they dynamically update machine code of the OS in memory on the fly for folks who can't tolerate downtime.

It's certainly not common on unix systems.

Or an IoT device running a 2.6 kernel that is never going to be updated. :)

Did Dolby break any countermeasures of Snap's copyrighted code in what would appear to be a significant reverse-engineering effort to make this determination?

Or do they only have a suspicion?

This scenario reminds me of the SCO lawsuits when the progress of technology made that company obsolete.

If Putin had been around, he'd have been in the Epstein files, too. It's vanishingly-unlikely that any strongman like that wouldn't also be a sexual abuser. It's all part of the same disrespect for others.

Linux has a large number of highly-paid developers. If you look at the kernel, specifically, there are basically no unpaid volunteers contributing significantly to it, and there haven't been for a long time. The right way to understand kernel development is as a collaboration between a large number of corporations, each of whom contributes the paid work of skilled engineers and most of which also contribute cash to a foundation that employs the highly-paid engineers who coordinate all of the work (notably Linus, who makes a seven figure salary -- honestly, ought to be eight figures, but he's certainly not hurting).

If you look beyond the kernel to the other tools and desktop environments, the volunteer participation rises significantly, but there's also a lot of paid work.

You cannot possibly know that.

This seems plausible, but it implies that you cannot possibly know whether we're going to get AGI this century. If it's true, it means that we'll get AGI when we discover that as-yet-missing knowledge, and there's no way to predict when that might happen. It might have happened yesterday and we just don't know it yet. What is certain is that (a) the knowledge exists and (b) we're looking for it, really hard.

Y2K is a better example. Y2K could have been a castrophe. A decade before it happened we started working to fix all the systems. Hundreds of millions of dollars (maybe billions) were spent on Y2K remediation. Then Y2K came and... nothing much happened. Lots of people pointed and said "Haha! All that money spent fixing the problem was a waste!", but they were wrong. All of the money spent fixing the problem fixed the problem.

This is what we have to do with cryptography and quantum computers. If we wait until practical QCs arrive, we'll be in big trouble. Not only will it take years to replace all of the classical crypto infrastructure, so we need to do the work before the QCs arrive, there are some cases where there will be no possibility of remediation. There are two major categories:

1. Harvest-now-decrypt-later (HNDL). Any cases where data needs to be protected for decades is subject to attacks that involve storing the data now and holding it until quantum computers can decrypt it. We undoubtedly have a lot of data that is already stored for later decryption, but we want to avoid increasing that risk further.

2. Hardware trust. Secure hardware requires trusted firmware, which requires burning public keys and verification algorithms into ROM, and many of these devices will be in service for decades. So we need to be able to deliver secure firmware updates for decades, using keys and algorithms we burn into ROM now. This is particularly relevant to me, because I'm working on firmware for automobiles, which have a 5-year development window, and a ~20-year (or more!) service life. So I'm working on systems that need to be securable through 2051, and it's pretty important because these vehicles have some degree of self-driving capability. A vulnerability that enables mass compromise and takeover could be used to mount a horrific terror attack.

So, yes, this matters. Probably. It's possible that practical quantum computing will never emerge, but given the tremendous progress over the last few years, that seems like a bad bet. Google's 2029 target is wise.

These statements are too strong -- in both directions!

First, although Grover's algorithm is proven to be the optimal quantum algorithm for generalized search, you don't necessarily need a generalized search algorithm to break a block cipher. Block ciphers have internal structure that may be exploitable by quantum algorithms. Indeed researchers have made some progress in designing quantum algorithms to break Feistel network-based ciphers (which AES is not, but the previous standard cipher, DES, is). The result of that work, Simon's algorithm, is not a practical way to break Feistel network ciphers, but more research may improve it. So it's certainly possible that researchers could identify AES substructure that can be attacked with quantum computers, and this could result in a quantum algorithm that breaks AES. We have no hint of anything like that, and no one is really considering it to be likely, but "quantum resistant forever" is too strong.

Second, the claim that QCs get you a halving of the bits for block ciphers using Gover's algorithm is technically correct, but overstates the practical reality. Even assuming we had large, reliable and cheap quantum computers, the way Grover's algorithm would be applied to breaking AES requires 2^(n/2) sequential operations, each of which is a non-trivial quantum circuit. Moreover, other practical considerations, which are way too complicated to get into here -- in large part because I don't really understand them; I'm repeating what more-knowledgeable colleagues say here -- mean that AES-128 will probably retain ~90 bits of security, which means it will probably remain secure forever, assuming no better-than-Grover's algorithm exists.

No.

What was shown is that one random number generation algorithm was found to have been backdoored at the NSA's request. There is no evidence that this has ever happened with any of the other NIST-standardized algorithms, and it's also known that the NSA has stepped into strengthen other NIST algorithms (notably, DES -- though the the NSA both strengthened that by improving the S boxes and weakened it by asking for a smaller key size, though that wasn't a secret weakening; everyone understands the implications of smaller key sizes, and where necessary there are easy workarounds, hence triple-DES, which is still secure today).

All of this was in the past when the NSA held a considerable lead in cryptographic knowledge over academic cryptographers. It seems very unlikely that this is the case any more, and in fact at this point basically all novel cryptographic knowledge seems to be flowing in the other direction.

The only other case that people do wonder about a little bit is the choice of the elliptic curves used for ECDSA and ECDH. NIST never published any rationale for those curve choices, or any publicly-verifiable information about their choices. Most likely this is because there was no systematic choice process; they chose curves at random, verified their security properties and went with it, but it's possible that these specific curves have some internal structure that the NSA knows about and can exploit, but the rest of the world doesn't. After decades of fruitless scrutiny this isn't likely, but it's possible, which is why Daniel J. Bernstein ensured that his Curve25519 did have a clear, rational and publicly-verifiable construction process, and that's part of why many systems prefer Ed25519 and X25519 over ECDSA and ECDH (Curve25519 is also faster and has smaller public keys).

In the case of the PQC algorithms, all of them were created by academic cryptographers, and there are no suspicious modifications. So if the NSA has backdoored them they've done it really, really subtly. IMO, it's not a risk worth worrying about unless you're specifically defending against the NSA, and probably not even then. For commercial work, like I do, it's sufficient to trust that if the NSA is smart enough to have learned from the Dual_EC_DRBG debacle. In that case, not only did the backdoor eventually come out fully, along with evidence that the NSA had paid at least one company to use that algorithm, academic cryptographers suspected its existence even before the standard was published, and spoke publicly about it. That was probably what motivated the NSA to pay for its use, since it was under a cloud of suspicion from the beginning. So it was a very foolish move by the NSA, driven by extreme and obviously unjustified overconfidence in their lead in cryptographic knowledge.