Title: On Rust Date: 14-09-2020 Category: Programming

Rust impressions from Python

My first attempt to Rewrite It In Rust - a model of the Tennesse Eastmann chemical plant - ended two weeks later, with me giving up and modernising the original Fortran to something from this centry, with a sour taste in my mouth.

I suppose what I really want to see, following this and the enormous hype train Rust has had, is critique of a language like Python from someone who actually understands why it took off and now runs half the world.

Let’s say you buy a Volvo, or most other reasonably modern cars. Id you do, there’s a good chance it will come with some sort of collision avoidance/mitigation feature. This feature is simple: a low-resolution RADAR that’s good enough to work out if something solid is rather close to your bonnet, connected to the brakes. It’s not a sophisticated device, it doesn’t prioritise passenger comfort, and it probably won’t avoid all collisions, but it generally mitigates. It is simple, brutal, and effective.

Introduction

Microcorruption is a Capture the Flag (CTF) type challenge based around Reverse Engineering and binary exploitation - kind of the stuff you might actually think about as “hacking”. There’s no actual flag as such. The system is a microcontroller so there’s no Linux-fu here either. Instead, your “microcontroller” is controlling a lock, and you defeat a challenge by finding the right sequence of inputs to open the lock.

Microcorruption is publically available and hosted on different servers, I’ve been using the one hosted by the NCC group. Hmmm, interesting people, but it’s a fantastic, intuitive setup.

A small snippet that came from discussing with a fellow PhD scientist - without any operational experience - on one aspect of COVID-19 testing.

“Okay, how many people would we need per machine?” “Well, let’s see, one person can saturate the machine” “Okay, so we need one person” “Okay so we need five people”

Computers have been used in chemical plant since basically the point at which computers* existed as a meaningful thing, which is to say, roughly post-WW2. Like most technology, war was one of the main drivers - firstly to brute-force ciphers, then to make better ciphers, then to guide missiles carrying thermonuclear warheads and work out how big a boom they’d make. I still use the language designed to answer that last question. I’d also, though I’m far from expert in this field, like to mention at least the design philosophy of the F-16 Falcon fighter jet, whereby instead of designing a plane a human flies, they thought of it as something a human commands, and the lower-level details are abstracted into a control system. You might say an Industrial one.

One of the things everybody seems to roughly agree on is that PKIs are useful, but hard. It’s easiest if your use case is running on the public internet, weirdly, since a) just use Let’s Encrypt, b) privacy was never expected. Even then, it’s telling that I’ve seen more than one security (!) blog eschew it.

PKIs are simply necessary for the public internet; since without that any security needs (n2) keys, where n in the number of computers in the network. (As Dale Peterson has previously pointed out to, erm, me). I’d argue that’s not even the biggest reason; the biggest is that without them or Kerberos, you just don’t really have a better authentication story than TOFU.