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.

This isn't true.

Yes, one of the finalists was broken, utterly. There are no successful attacks against ML-DSA, ML-KEM or SLH-DSA, and they have good security proofs. Note that "successful attack" and "security proof" both have different meanings to cryptographers. A successful attack is one that reduces the security even a little from what it theoretically should be, even if the reduction still leaves the algorithm completely unbreakable in practice. A security proof is a proof that the construction is secure if the underlying primitives satisfy security assumptions. There is no cryptographic algorithm in existence that has a security proof that a mathematician would consider to be a proof; we just don't know how to do that. In the case of ML-DSA and ML-KEM, the underlying assumptions are about the hardness of the underlying mathematical problems, Module-LWE and Module-SIS. In the case of SLH-DSA the underlying assumptions are about the security of hash algorithms.

Module-LWE and Module-SIS are fairly new problems, and have only been studied for a little over a decade. The whole field of mathematics they're based on is less than 30 years old, so it's more likely that some mathematical breakthrough will destroy their security than it is that some breakthrough will wipe out ECC, which has been studied for about 50 years, and which builds on 150 years of algebraic geometry. Still, a mathematical breakthrough could destroy ECC or RSA, too.

In contrast SLH-DSA is rock solid, from a security perspective. We've been studying hash functions for a long time, and, really, our entire cryptographic security infrastructure is based on the assumption that our hash functions are good. If that turns out not to be the case, then quantum computers will be the least of our problems because to a first approximation every cryptographic protocol in existence relies on secure hashing. It's far more likely that ECC or RSA will be broken than that SLH-DSA will be broken. Unfortunately, SLH-DSA is orders of magnitude slower than what we're used to.

It's worth noting that SIKE (the NIST PQC finalist that was broken) also had a security proof. The problem was that the proof showed that SIKE was secure if the supersingular isogeny problem was hard -- but what SIKE actually used wasn't that problem, exactly. SIKE required additional data to be published, and that additional information reduced the hardness of the problem. This is why the break was so total, and was found immediately when researchers began scrutinizing SIKE. All it took was the observation that SIKE relied on a less-hard problem, then a mathematical solution to the less-hard problem.

NIST chose these three algorithms for good reasons. ML-KEM and ML-DSA have larger keys than we're used to with RSA and especially ECC, but they're not that much larger, not so large that they simply can't be used in existing protocols. And they're fast, with performance on par with what we're used to. So they are feasible drop-in replacements in most cases.

SLH-DSA is not a drop-in replacement. The keys are very small (on par with ECC, a bit smaller, even), but the signatures it produces are enormous: the smallest is 8k, the biggest is 50k (depending on parameter choices). Also, signing is 50-2000 times slower than EC-DSA (depending on parameter choices) and verification is 10-30 times slower.

So, what NIST did was choose a pair of quite-usable and probably-secure algorithms (ML-KEM and ML-DSA) that cover all cryptographic needs and are very close to being drop-in replacements, plus a less-usable but absolutely-secure algorithm as a backstop. I don't know that they ever explicitly stated the strategy they were suggesting, but it's obvious: Use ML-KEM and ML-DSA as your everyday algorithms for operational security and for firmware signing, but for firmware signing specifically, burn an SLH-DSA public key into your devices that you can use to verify new firmware and new public keys that use new algorithms in the event the ML- algorithms are ever broken.

I don't think so, and neither does Google -- which employs a lot of professional academic cryptographers (which I'm not).

Whether you should move to these algorithms depends on what you're doing, and what your service lifetimes are. If the data you're encrypting or signing only needs to be secure for a decade, don't bother. Existing ECC-based constructions will be fine.

If the data needs to be secure for more than that, if you're really concerned about harvest-now-decrypt-later attacks that could be performed 20-30 years from now, you should move to ML-KEM, and do it soon. There actually isn't that much data that really needs to be secure for that long... but if yours is in that category it's more likely that it will still be secure in 2050 if it's encrypted with ML-KEM/AES than if it's encrypted with ECDH/AES. Both options are a gamble, of course. ML-KEM is more likely to fall to a cryptographic attack than ECDH, but ECDH is at risk from quantum computing.

Firmware signing is a very interesting case. Firmware security is foundational to system security. Phones today are expected to have an ~8-year lifespan, so a phone launched in 2029 needs to remain secure until 2037... and that is getting into the range where there's a non-trivial probability that quantum computers will be large enough, reliable enough and cheap enough to be a threat. That probability is only in the 1-5% range (IMO), but in the cryptographic security world 1-5% is utterly unacceptable. I work on automotive firmware these days (I left Google six months ago) and we have ~5 year development timelines, followed by 20-year operational timelines, so a project we start today needs to be secure until 2051. The probability of large, reliable, cheap quantum computers by 2050 approaches 100%.

On the other hand, can your hardware really accept a ~20X longer firmware verification time from using SLH-DSA? That's not a question with a universal answer. Some contexts can, some can't. ML-DSA is more computationally-practical, but there's a risk that it will be broken. I think the clearly-appropriate strategy for now is: Ship your hardware with ML-DSA verified firmware, but also burn an SLH-DSA public key into the ROM (or OTP fuses) and arrange things so you can use that SLH-DSA public key to verify and install a new firmware verification scheme in the future, should ML-DSA be compromised. Or, alternatively, stick with EC-DSA or Ed25519 for now, but include that same SLH-DSA-based infrastructure for migrating to something else. If your hardware lifetime is long enough, you almost certainly will have to actually use that to migrate to some PQC algorithm. If feasible, it would be better to start with ML-DSA now.

A truly non-lazy person, then, would have to conduct a detailed spectrographic assay of all of the pipes (or at least sufficient samples from each lot) to accurately determine the precise composition of each, because all of them contain impurities and aren't merely copper and phosphorous.

In general, getting a truly pure sample of almost any element is incredibly-hard, and outside of laboratories (and even in laboratories, most of the time) it just doesn't matter. In the case of transporting anti-protons, standard "pure" copper is apparently inadequate, because it's not pure enough.

Even with the reduced precipitation there's still plenty of water for residential and commercial use. The problem, at least where I live (Utah), is agriculture. 80% of our water goes to agriculture. It would be one thing if we were growing regionally-appropriate crops for local consumption, but nearly all of that agriculture is to grow alfalfa (a water-hungry crop that isn't appropriate for the high desert climate), and nearly all of that alfalfa is shipped out of state, much of it out of the country, to feed cattle elsewhere. China is one of the biggest buyers. Essentially, our farmers are selling the contents of our aquifers to the world.

If we had plenty of water, letting our farmers buy it at a deep discount and sell it to willing buyers elsewhere would be fine, just another commercial use of a local resource, which is what trade is all about. But we definitely don't have plenty of water.

The solution is simple and straightforward (though legally complicated): Don't discounts. Set the same price for water across the board, residential, commercial and agricultural. There can and should be minor differences in delivery cost, and surcharges for purification, but the base cost of the water should be set through a single government-managed market, probably at the state level, probably divided up by drainages (drainages with more abundant water will have cheaper water; if this creates an arbitrage opportunity for someone to pipe water between drainages, great!).

Yes, this would probably put the alfalfa farmers out of business, but that's good because growing alfalfa in the desert is a bad idea. It might also raise the price of local produce, but that's as it should be, putting agricultural water use directly in competition with other water use. If prices go up, people will find ways to be more efficient. Farmers may switch to drip irrigation. If you build too many houses for the available water supply, well, those houses are going to have very expensive water and residents are going to want to find ways to conserve -- and maybe the high cost of water will disincentivize new move-ins.

The bottom line is that efficiently allocating scarce resources is what markets are good at. The problem with water isn't that there are too many people or not enough water, the problem is that we don't properly allocate the water or encourage conservation in the right places. Trying to fix this through regulation rather than market pricing will always be subject to regulatory capture and will never be as efficient or as effective as just enabling a competitive market and letting it work.

This is part of what Colbert wants to fix. His proposed film will cover the largely-omitted chapters 3-8 of The Fellowship of the Ring, including the barrow wights and Tom Bombadil.

No idea. It's fine so far, but I've only had it for a few months. Honestly, I'm pretty brutal on devices. Odds are high that I'll break it in some other way before the flexing causes a problem.

In a case like that I think Claude is "smart" enough to push back. Claude often catches my mistakes. It's also pretty easy to add rules like "Request confirmation for any purchase requests that are unusually large or otherwise out of the ordinary for the user. Review past purchases to determine user purchasing patterns." to make this explicit.

Claude is far, far smarter than Alexa.

OTOH, it sometimes does do stupid things. On balance, I think I screw up more often than it does, but you can't just assume it will make the right decisions, so adding rules that require doublechecking with the user is a good idea.

Without a foldable phone, I'd agree. With the foldable, I can unfold it and have a reasonably large on-screen keyboard, which I can type on with both thumbs. And of course my phone is always with my, while a tablet would be an extra device to carry -- and if I'm carrying an additional device, the laptop is more functional.

Me too. I looked! Termius + tmux works reasonably well, but an app specifically for this purpose would be nicer.

I use the Termius app on my phone, SSH to my workstation, run tmux attach -d to attach to the tmux session in which I'm running Claude, then tell it to do stuff. It can only do stuff that can be done via the command prompt, HTTP requests or MCP integrations (Gmail, Drive, Confluence, Jira, etc.), but that covers a lot of ground. "Only what I can do from the command prompt" is not much of a limitation.

I've told Claude to write a design doc in Confluence (which I reviewed and shared with others to get feedback); then implement the feature, including tests; build and run the code and tests on two hardware platforms (the host and an attached embedded QNX board); commit the code to a feature branch and push the branch upstream (where I reviewed it and told Claude what to fix); create a pull request; respond to reviewer comments; and merge the PR, all from my phone while a thousand miles from the workstation. I've only done the complete cycle from the phone once, but I've done pieces of it many times.

To make this work well, it helps to have a phone with a big screen. I have a Pixel 10 Fold, unfolded for Termius use. A tablet would be better... but if I'm going to lug a tablet around, my Macbook is better yet, since it's not that much bigger than a tablet and has a keyboard. And, obviously, I do reach for the laptop rather than the phone if I have it. But I can get a lot done from the phone.

This new feature is basically "Let poor GUI users do what command-line jockeys have been doing for a while".

This isn't true.

Members of Congress and congressional employees are not exempt from the insider trading prohibitions that apply to everyone else. Trading on non-public information is a crime. In addition, if they're trading on classified information, the mere act of making the trade could constitute public disclosure of classified information, which could constitute several additional felonies, potentially including treason if the disclosure aids enemies of the United States.

However

While what you said is patently false as a matter of law, in practice there's basically no enforcement of the law against members of Congress. So, while your statement was wrong, you could say "Insider trading is ignored when done by a member of Congress" with near 100% accuracy.

The fix I would propose is not to ban members of Congress or their staffs or immediate families from trading, but instead to require them to disclose all trades 48 hours in advance. This wouldn't change the legality of trading on insider info (it would still be illegal), but it would serve to eliminate most of the benefit of acting on insider info, because their disclosure would move the market. Violating the disclosure requirement or failing to follow through on a disclosed trade would incur a fine equal to 150% of the value of the trade. This should be coupled with a requirement that members of Congress put their prior holdings into a blind trust and refrain from trading in any security over which they have a direct regulatory role.

I think that's a terrible white vs blue collar crime example. Sports betting with co-workers is ubiquitous, but if anything is even more common in blue collar workplaces.

Last weekend, Trump announced plans for massive strikes against Iran's civilian infrastructure (unequivocal war crimes, if carried out). Oil futures spiked. At 7:05 AM yesterday, Trump announced that his strikes were on hold for five days because he's negotiating with Iran [*]. Oil futures fell... but the fall actually started before the announcement, because at 6:50 AM oil futures trading volume spiked as someone suddenly offered for sale large contracts they'd been holding. There was no news that could have motivated those sell offers. The parsimonious explanation is that someone knew Trump's announcement was coming, and cashed in.

I'm sure Trump's DoJ and SEC will be conducting a thorough investigation into who sold 15 minutes before Trump's announcement, and what motivated them to make that move when they did, and will be aggressively prosecuting those who acted on insider information and those who leaked national secrets to them. </sarcasm>

My point is that prediction markets are utterly irrelevant in this situation. There are and always will be vastly greater opportunities to cash out on insider knowledge by trading in real commodities that play an actual role in the global economy. Argue for banning prediction markets if you like, but trying to claim that doing it will prevent insiders from making money on their inside knowledge is ludicrous.

[*] Note that Iran denies that it is in negotiations with Trump.

I have never, ever heard loan forgiveness called a "refund", in any context, anywhere. The label makes no sense at all.

A refund is when I return to you money that you have paid me.

Loan forgiveness is when I tell you not to repay me money that I gave you.

These are completely different things. In the loan forgiveness case, there is no "fund" being "returned". I challenge you to find any dictionary that defines refund in a way that would apply to loan forgiveness. I'm not making a political statement here, or taking a position on Biden's actions, I'm talking about the meanings of words. I think it's important that words have meanings. If we humpty-dumpty all words, we'll have no way to communicate, and that would be a bad thing.

That's an... odd... definition of "refund".