No you really can't. Being able to factor 15 but not 21 with Shor's algorithm is normal. I know it sounds absurd, but it really is that way. Because factoring 21 is about 100x times harder than factoring 15.
My point was that the comparison with nuclear explosions is wonky, since we (in the world of that analogy) already have seen a tiny nuclear explosion 15 years ago. And we kept being told that explosions 100 times larger are just around the corner, but explosions 25% larger are way too hard to expect.
I get that there's a lot of R&D going on to make larger quantum computers a thing and that there's been very definite progress, but factoring 21 is just too hard to expect for now. But that also pushes the date where pre-quantum cryptography is broken further into the future. If we still struggle to factor one of the smaller 5 bit numbers, factoring the 128 bit numbers necessary to break elliptic curve cryptography seems quite far away.
Hydrogen has a volume problem, though. A 1st generation Toyota Mirai contains 5 kg of H2, equivalent to 197 kWh. That would take up 55 m3 at atmospheric pressure which is why the Mirai stores it at ~700 atmospheres. That's still a 78 liter tank. AFAICT 200 kWh of petrol takes up 25 liters, i.e. a third. On top of that the high-pressure tank in the Mirai weighs 87 kg.
Hydrogen also sucks in that it puts you in your own scaling lane. Relying on batteries means EVs, grid storage, et cetera drive down your costs for “free”.
Bertha Benz faced a similar problem in 1888, and had to refuel the Patent-Motorwagen by seeking out pharmacies. Drivers of the steam cars that were popular in France could just pick up a bag of coal from anywhere. (Wait, that doesn't sound right. A bottle of kerosene, then.)
I like the idea of fuel cells, but hydrogen's going to have an image problem as soon as people see the failure mode, if it's just being stored as H2 in compressed tanks. Liquid fossil fuels and electric batteries burn with a gradual flame. Hydrogen suddenly detonates, with a supersonic, shattering shockwave, if it's mishandled.
Even with Cold War money, Lockheed's famed Kelly Johnson couldn't make the logistics work for the CL-400.
In Haskell it's only ever one of (A(B)(C) or (B(A)(C), and you can tell which based on which characters B is made up of. If B starts with one of !#$%&*+./<=>?@\^|-~` it's the second situation, otherwise it's the first.[0] All functions are unary in Haskell so A(B, C), B(A, C) and C(A, B) can never actually happen. The cases where it looks like A(B(C)), etc. are happening are actually cases of (B(A)(C), e.g. f $ g is a (B(A)(C) case where B=$. So the basic syntax of Haskell is actually very simple and consistent, but due to lazy evaluation the functions can affect control flow much more than in other languages.
0: OK, there are some additional non-ASCII Unicode symbols, but everything but string literals should be kept ASCII IMO.
As a software engineer with a good amount of freedom to choose what tools I want to use, what can I do presently to move towards post-quantum cryptography? AFAIK the hashes and symmetric cyphers that are in wide use are already resistant, leaving mainly public-key cryptography as the problem. Is there, for instance, a drop in replacement for `ssh-keygen -t ed25519`?
I have another comment[1] on this post with more practical instructions, but the `ssh-keygen` is a good question. The cryptography community is still focused on migrating encryption/key exchange algorithms, for fear of data being captured today and decrypted in the future. So OpenSSH 10.0+ already enables ML-KEM by default.
SSH keys, on the other hand, are authentication and would require an online Quantum Computer to break, so we have more time. Authentication is also (usually) more complicated, so there are still disagreements on what to do with the Web PKI for example. To give you a concrete target, Google, Microsoft, and CloudFlare have self-imposed deadlines of 2029 for their PQC migrations.
In practice, PQC migration means updating your software, bugging your vendors to ensure they have this on their roadmaps, and making sure your own code is flexible in respect to algorithms used.
Late edit: PQC migration also includes sometimes changing configuration files/library invocations to enable the new algorithms, and ensuring that your processes still work during the migration, where you might have both pure classical and PQC/hybrid at the same time.
I just went through some ~/.ssh/config files and realized that, along side the entries for ancient systems that need to be forced to use undesirable ciphers and Kexies, I also had some entries for current systems that stipulated only the "good" values, to "protect me from hypothetical future downgrade attacks". Which means that I wasn't getting the latest PQ Kex, because my entries hadn't been updated since ssh 9.x.
Maybe the best practice here is to have one or more Boppers on your team who send out periodic notifications to update not just algos in libraries but, more importantly, make sure those updates are reflected in the damned configs.
We also really need a cultural shift where it becomes expected that, for any given app, we have something like:
$ ssh --best user@host
which does that for us. Because this is a failure mode that shouldn't even be possible for most users and cases.
There are also scanners that you can deploy to identify vulnerable servers, like https://sshcheck.com/ . Clients are harder to check, but you can always observe your logs.
On a separate note, I've definetly been hearing worried murmurs about "harvest and decrypt" attacks along with post-quantum TEE slightly before the GCP paper, and I definetly think it appears a couple nation states are on track for a "quantum leap" by 2030 given the rate at which I've been hearing it within my network.
How does that work when Diffie Hellman key exchange is ephemeral and so compliant servers couldn’t even roll back sessions if they wanted, to let a MiTM
We're almost done countering store-now/decrypt-later, but the biggest part of the job, post-quantum authentication, still remains. Like Google, we target 2029 to be done .
SSH is working on a drop-in as we speak. TLS is further along: most stacks already support X25519MLKEM768 (by default!) to counter store-now/decrypt-later. PQ certs are not widely supported yet, but that's being sped up as we speak.
I am reminded of a certain comedian who lost his job hosting an awards ceremony because he had once said something on stage that people didn't like....
...8 years previously.[1]
Long, long ago in a datacenter far away, breaking 3DES used to be the province of expensive bespoke hardware owned by only the elite nation states. Today it is so trivial that the gpu in your second hand laptop can do it "at scale".
5 years ago ChatGPT was a wet dream.
We should be very conservative in our planning where future security is concerned. The only thing we can be sure of is that Murphy's Law is looking for every chance to make us look foolish.
As far as I know, cracking 3DES is still not trivial, and requires a very large number of operations and/or a very large amount of data. But can just about be done in some situations.
If you have any link to trivially cracking it on your second hand laptop and doing it at scale, would be very interested.
An AG corporation has stocks in order to track who owns how much and also attach different economic and voting rights to different classes of stock. The other way to incorporate a limited-liability company in Germany is the GmbH, which tracks ownership directly in the articles of incorporation, but are in other ways subject to way lower management, disclosure and accounting requirements. So the AG is mostly useful if you want it to be easy to change your ownership structure, if you for instance raise capital from new investors, issue employee shares, change cross-ownership within a conglomerate or go public some day.
Why Carl Zeiss is an AG I don't know. The West German Carl Zeiss was re-formed as a GmbH in 1946, but had changed to an AG by 1973. The East German Carl Zeiss was turned into a GmbH during reunification and then split in two. One part merged into the West German Carl Zeiss AG and the other is now called Jenoptik. Jenoptik was converted into an AG in 1996 and went public in 1998. AFAICT Carl Zeiss has been privately owned by the Carl Zeiss-Stiftung since 1889, except of course for the temporary East German part.
How does it make sense that the show ignores INSAG-7 when the whole plot point about the design of the control rods increasing the reactivity isn't from INSAG-1 but from INSAG-7? The same with the plotline about this defect being known, but kept from the operators. And Legasov lying about all this at the IAEA meeting? All-in-all INSAG-1 paints a picture of operator failure, INSAG-7 paints a picture of systemic failure and the show paints a picture of systemic failure.
And to nitpick: INSAG-7 doesn't disagree with INSAG-1 about the power rising just before AZ-5. From page 8 of INSAG-7: "When the turbine was tripped, the four pumps it was powering began to slow
down as the turbine speed was reduced and the associated generator voltage fell. This
reduced rate of core flow caused the void content of the core to rise and caused an
initial positive feedback of reactivity which was at least in part the cause of the acci-
dent." (page 8) This happens ~30 seconds before AZ-5 is pushed.
The same event described in Table I on page 21-22 of INSAG-1, with the part deprecated by INSAG-7 marked with {}:
01:23:04 {The personnel blocked the two-TG trip signal.} Emergency stop valve to the turbine was closed. The reactor continues operating at a power of 200 MW(th).
01:23:10 One group of automatic control rods start driving out
01:23:21 Two groups of automatic control rods begin reinsertion.
01:23:31 Net reactivity increasing with subsequent slow increase in reactor power.
The textual description on page 25 of INSAG-1 isn't much different: "When the emergency stop valve to the turbine was closed, the steam pressure began to rise. The flow through the core started to drop because four of the main cooling pumps were running down with the generator. Increasing pressure, reduced feedwater flow and reduced flow through the reactor are competing factors which determine the volumetric steam quality and hence the power of the reactor. It should be emphasized that the reactor was then in such a state that small changes in power would have led to much larger changes in steam void, with consequent power increases. The combination of these factors ultimately led to a power increase begninning at about 01:23:30."
> neither the reactor power nor the other parameters (pressure and water level in the steam separator drums, coolant and feedwater flow rates, etc.) required any intervention by the personnel or by the engineered safety features from the beginning of the tests until the EPS-5 button was pressed. The Commission did not detect any events or dynamic processes, such as hidden reactor runaway, which could have been the event which initiated the accident. “
Sure, I'm just saying the power increase did happen, according to both INSAG-1 and INSAG-7. Neither INSAG-1, INSAG-7 nor Legasovs report claims there is a rapid increase in power before AZ-5 is pushed. The claim in INSAG-1 is that this power increase was the start of a positive-feedback loop that caused the explosion. The claim in INSAG-7 was that the power increase was not a safety problem, except to the extent it caused the operator to push AZ-5.
I can't find any description of the test across the three reports mentioning that that emergency stop button is supposed to be pressed as part of the test. AFAICT the test wasn't even completed when the button was pressed as the purpose of the test was to demonstrate that the emergency core cooling system could run for at least 40 s (INSAG-1 page 17) after closing the turbine emergency stop valve. That valve was closed at 01:23:04 and AZ-5 was pressed at 01:23:40.
For the rundown test, after the valve cut-off, it is irrelevant whether the reactor was shut down or not. The working plan for the test only specified that it was supposed to run before a planned maintenance period, so the shutdown was implied. During previous tests, the AZ-5 signal was wired to the valve cut-off signal and was sent automatically at the same moment. It is not clear why this changed in 1986, but the outcome would have been the same if AZ-5 had been pressed 35 seconds earlier.
Can you point to anywhere in INSAG-7 where they talk explicitly about that? Because if not your point about the show ignoring INSAG-7 falls a bit flat.
This information is not discussed in INSAG-7. It is from trial testimonies sourced from the book by Nikolai Karpan (deputy chief engineer of Chernobyl NPP), who was present at the trial and made notes himself.
Those of us who live in apartments and charge our BEVs with public chargers also mostly charge while we sleep. If your battery is large enough for a week or two of normal use, leaving the car in a public AC charger overnight when you get down to 10% charge left is by far the easiest. And AC chargers are generally also cheaper than DC chargers.
Sure, but the problem with coal and oil is not their chemical composition, per se. The problem with specifically fossil coal and oil is that the carbon atoms used to be buried deep underground and end up as part of CO2 molecules in the atmosphere. Making synthetic kerosene for jet engines is one of the top contenders for long-distance air travel in a post-fossil fuel world, IMO.
Germany: electricity 56% renewables, 4% GDP growth since 2021Q1, 6.4% unemployment
Denmark: electricity 92% renewables, 14% GDP growth since 2021Q1, 2.7% unemployment
I don't think renewables are what's wrong with Germany, more likely it's a) their lack of infrastructure investment and maintenance in the past decade-an-a-half, b) their excessive coddling of established and well-connected businesses.
reply