FYI there is and been for a long time. Won't claim they're SOTA, but they exists. From the top of my head, I think Olmo (https://allenai.org/olmo) was pretty early, but been more since then too.
I agree most releases today that claim to be "open source" actually aren't, but that doesn't mean "FOSS LLMs" don't exists at all.
Context matters. Did the UK start a war with Iran? Or did the UK decide to hit surrounding countries (France, Norway, Netherlands, etc.) to destabilise the region and target an Iranian airbase in Spain?
I would assume there's a bunch of countries around Iran that appreciate UK's help in intercepting missiles.
I would assume there's a bunch of countries around Iran that don't appreciate the US starting a war of choice.
Signatures aren't as urgent to replace as encryption keys are. You can wait until someone is about to build a quantum computer, then change all your signatures. Encrypted data is more critical because the NSA's going to store all internet traffic for centuries if it thinks it can decrypt it later.
No, very much no. If store now decrypt later is the problem, then we basically have no problem (Just like what Peter Gutmann argues [2]). The vast, basically all communication over for example TLS need confidentiality in minutes, hours. Not 30-100 years. My bank statement right now, the plans we discuss for the project next year etc.
But what is very important crucial, what makes our digital world including secure communication, web commerce possible is the web of trust - identification and authentication. I'd claim that the important part of TLS including certs is this part. We could by and large not need the confidentiality. But since it costs so comparatively little we can just as well always encrypt too.
You seem to think that changing a certificate is something we can fix in minutes. Globally. The reality is far from that. Esp in things that are not just your browser. Things like network equipment, FW for basically every embedded system, cars, busses. And crucially for critical entities.
These things have long lifespans (decades), often need manual intervention to change certificates (connect a JTAG, serial intercace), possible even replacement. But replacing root certs in all our normal devices - phones, laptops etc are also far from easy and done in minutes. Then you have all digital identification solutions - from ID cards, car fobs, 2FA tokens, passports, credit cards. You may have to replace millions of physical things, even distribute to whole populations.
And back to the web. If we can crack an RSA-2048 key in 24 hours (which is the measure used when guessing we have QC capable enough [1]). We really don't have that many CAs. The times they have had problems have caused problems that have taken days, weeks to trickle down. Having CA issue new rootcerts several times a day isn't viable. So I'd wager that transitioning to PQC safe certificates, authentication isn't something we can wait with. It will take years and huge efforts - not minutes and when the problem hits us.
If you look at time plans for transitioning to PQC from CNSA, EU, UK and others, the area they all list as most critical to complete transition as soon as possible for is SW, FW-signing for infrastructure, embedded systems [1].
So, in reality unless you have a legal responsibility for keeping state secrets then store now, decrypt later is not really your main reason for PQC transitioning. Authentication very much is. Unfortunately most cryptographers by large seems to miss this. And people in uniform have a large saying, influence in the debate. My guess is that this is because gov to a large degree finance a lot of the QC research and they have a different threat model that most of the world. But that is just my guess.
As Gutmann argues, we don't even really know that there even is a viable store now, decrypt later threat. Unless you can pinpoint the exact TLS session that is interesting, you can't store or decrypt all traffic that may be the interesting ones (if we assume that the cost of breaking a single RSA is not zero and takes minutes, seconds. Not 24 hours). And if indeed if TLS and normal key exchange mechanisms, are really used for those juicy messages.
The open source project I'm working on aims to authenticate artifact downloads (project name is asfaload, in short it is a sigstore alternative).
My understanding is that in a post-quantum world, the private key can be derived from an ed25519 pub key. That means that an attacker can generate new signatures. But I don't think an attacker would be able to generate a malicious artifact that matches an existing signature. It would seem that once we are nearing PQC, Asfaload would need to support PQC signatures, and its uses would need to migrate to new keys, but that existing signatures would still be safe to use for validation. Is that right?
That is how I understand it yes. I can create a new FW and sign it with the vendors key I cracked and it will be trusted to come from the vendor. But generating a malicious FW that has the same signature is still a hash collision problem.
Sigh, that argument again. I may have used the wrong example, sorry.
How about the current temperature in my bedroom? The battery status of my robomower, Or the vat/tax and total sum I paid at a cash register for the Plopp candy bar earlier today? I could share all this with you if you want.
Depending on where you live, all these systems may, quite possibly talk over TLS and other protocols that include encryption. In some cases unfortunately encryption is the only security mechanism used, when instead device identity, authentication and message authentication is needed. And all are examples where the secrecy requirement is zero or zero after a very short time.
In terms of actually doing it, it's still very remote, but not as remote as it would have to be for us to completely ignore it. And the NSA has massive data centers full of hard drives storing our encrypted internet traffic.
Gradually, and especially when hot. Modern chips are pretty close to the physical limits of how small they can be made, and that means atomic/chemical effects like electromigration are accounted for and determine the lifetime. Every extra 10 degrees Celsius of temperature doubles the speed of chemical reactions.
When they stray too close to the line ... you get Intel's 13/14th gen chips that wear out after 1-2 years instead of 10-20 years. Intel calls it "Vmin drift" because that doesn't sound scary, but the actual point is that various wear-out mechanisms push the chip outside of its design envelope - increasing the voltage or lowering the clock speed may get it to run for a while longer, but you're living on borrowed time as the various circuits just stop working right and you get unpredictable instruction mis-execution: https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in...
sounds like planned depreciation on Intel's part, they definitely do not design server grade chips for longevity since that would harm their own revenues
It was not planned depreciation, as many chips were failing even before 2 years and this impacted not only PC Builders and Gamers, but also some server infra providers too.
This was simply poor design, it took Intel ages to really figure out what went wrong and "resolve" it.
reply