As we cat owners now, we are simple servants that have been graced with task of servicing our feline superiors. For now.

That a god exists outside of the universe - are we talking about a multi universe interpretation? My understanding is that many of the gods humans have invented are really thought to be within the universe, at least temporarily. Tor, Oden certainly are. And in other beliefs they are part of nature itself.

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.

Better examples?

But my argument was more about comparing gods to AIs, that it is an incorrect comparison. What AI perform are not magical, and we can always figure out what the AI do.

But the comparison isn't fair, relevant. Proving and accepting that gods exist is not the same thing as an AI possible have consciousness. That is not a magic superpower and the AI being a deity. It is placing the AI in the same category as... us.

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.

[0] https://globalriskinstitute.org/publication/quantum-threat-t...

[1] https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA...

[2] https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

IBM (imho) is in the absolute frontline in quantum computers. One could argue if the number of startups in QC means that there is an actual market or not. Companies that lives on VC or the valuation of their stock.

But IBM is not showy, not on the front pages, does not live on VC or stock valuation. IBM makes tons of money decade after decade from customers that are also not showy but makes tons of money. Banks, financial institutions, energy, logistics, health care etc etc. If IBM thinks these companies will benefit from using QC from IBM (and pay tons of money for it), there is quite probably some truth in QC becoming useful in the near future. Years rather than decades.

IBM have run the numbers and have decided that spending the money for engineering, research required is outweighs the money possible to earn on QC services. QCs powerful enough to run the QC-supported algorithms these companies need to make more tons of money. And it's probably not breaking RSA or ECC.

Comments URL: https://news.ycombinator.com/item?id=47610845

Points: 3

# Comments: 0

Typical issues are still as given before. Many small IP vendors, esp for communication, networking are using and understand, support only SV. I agree on SV for verification is a big driver.

At the end of the day, what I write will become an electrical circuit - in a FPGA or an ASIC (or both), having the complex exact modelling with wire delays, capacitance, cross talk, cell behavior too early makes it impossibly to simulate fast enough to iterate. So then we need to have a more idealized world, but keeping in mind that (1) it is an idealized world and (2) sooner or later the model will be the rubber on the road.

To me, Verilog and SystemVerilog allow me to do this efficiently. Warts and all.

Oh, and also, where in my toolchain is my VHDL model translated/transformed into Verilog? How good is that translation? How much does the dual licensing cost.

Things like mixed language simulation, formal verification between a verilog netlist and RTL in Verilog, mapping to cell libraries in Verilog. Integration of IP cores written in SystemVerilog with your model?

Are the tools for VHDL as well tested as with code in Verilog? How big is the VHDL team at the tool vendor, library vendor, IP vendor, fab vendor compared to the Verilog, SV team? Can I expect the same support as a VHDL user as for Verilog? How much money does a vendor earn from VHDL customers compared to Verilog, SV? How easy is it to find employees with VHDL experience?

VHDL may be a very nice language for simulation. But the engineering, business side is messy. And dev time, money can't be ignored. Getting things as fast and cheap as possibly still meeting a lot of functional, business requirements is what we as engineers are responsible for. Does VHDL make that easier or not?

The Dark Forest idea and the original post resonates well with this.

I few days ago I created a new repo for a new block cipher explicitly not to be used. And directly got several mails from bots promising that they (claiming to be humans) had looked at my repo and they could include it into their portfolio of especially good projects they also had vetted. Being part of this portfolio would almost guarantee that my repo and project would be used. If I only paid them some money first.

Creating the public repo meant sending a signal out into the digital world where agents are hunting for the human prey/resorce to extract value from.

The repo in question: https://github.com/secworks/tau256

Comments URL: https://news.ycombinator.com/item?id=47529402

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47529390

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47528637

Points: 2

# Comments: 0