Monthly Archives: March 2014

Strange terraforming

Working on the upcoming Raspberry Pi programming workshop for dBsCode, I’m wrapping the Minecraft Python API with a functional style one to reduce the amount of syntax we’ll have to teach. The idea is to build complex 3D shapes via abstraction, out of simple primitives.

dbsmcpi

The IDE we’re using is Geany which seems to run well alongside Minecraft on the Raspberry Pi so far. It’s great how Minecraft stays on top of the display at all times – more an unintentional feature of the GPU driver, but very useful for teaching.

Egglab – pattern generation obsession

I’m putting the final pieces together for the release of the all new Project Nightjar game (due in the run up to Easter, of course!) and the automatic pattern generation has been a focus right up to this stage. The challenge I like most about citizen science is that along with all the ‘normal’ game design creative restrictions (is it fun? will it work on the browser?) you also have to satisfy the fairly whopping constraints of the science itself, determining which decisions impact on the observations you are making – and being sure that they will be robust to peer review in the context of publication – I never had to worry about that with PlayStation games :)

variation

pattern2gen

With this game, similar to the last two, we want to analyse people’s ability to recognise types of pattern in a background image. Crucially, this is a completely different perception process from recognition of a learned pattern (a ‘search image’), so we don’t want to be generating the same exact egg each time from the same description – we don’t want people to ‘learn’ them. This also makes sense in the natural context of course, in that an individual bird’s eggs will not be identical, due to there being many many additional non-deterministic processes happening that create the pattern.

The base images we are using are wrapped Perlin noise at different scales, and with different thresholds applied. These are then rotated and combined with each other and plain colours with the browser’s built in composite operations. Ideally we would generate the noise each time we need it with a different random seed to make them all unique, but this is way too slow for HTML5 Canvas to do (pixel processing in Javascript is still painful at this scale). To get around this we pre-render a set of variations of noise images, the genetic program picks one of four scales, and one of two thresholds (and one without threshold) and we randomly pick a new variation of this each time we render the egg. The image at the top shows the variation that happens across 6 example programs. Below are some of the noise images we’re using:

noise-patterns

Scratch -> Lego Mindstorms

A bit of hardware hacking for Troon Primary CodeClub, who have tons of old style Lego Mindstorms they don’t use any more, and after a year of Scratch programming on their PCs are just getting started with Raspberry Pi. We’re using this Scratch modification together with the hardware I’m making which is based on this circuit. The main thing here is an L293D Motor Controller IC which can drive 2 DC motors in both directions. You can write the hardware code in Scratch like this to control the lego motors:

blink11

The most tricky part in this whole endeavour has been physically connecting to Mindstorms. At the moment I’m having to use crocodile clips which won’t work long in normal classroom conditions – but I’m wary of destroying/modifying the connectors as they’re not made any more…

IMG_20140317_111808

How to back up your encryption keys

Without really noticing it I’ve gradually acquired more and more encryption keys without understanding how to back them up properly. Until fairly recently I lazily assumed that remembering the passphrases would be enough in case of my laptop catching on fire, but this is not the case.

I use GPG keys both for authenticity over email, and encryption when sending people passwords for stuff I’m setting up for them. The Ubuntu launchpad also uses GPG for signing packages for which I use a different key. I also run a bunch of servers, for which I use ssh keys to prove my identity, then there is the Android play store, that requires binaries to be signed, using yet another key, which is also shared for OUYA packages too.

The main algorithm in use for authentication in all these cases is called RSA. RSA and similar algorithms generate a pair of keys, one public and one private. The private key data is encrypted using yet another algorithm (usually AES) which is what your passphrase is used for. When it’s needed, you type your passphrase in, it decrypts the RSA private key and uses that to identify you. So it’s vitally important that this key data is backed up as it can’t be recreated from your passphrase. There doesn’t seem very much information online on the practicalities of all this, so I’m documenting the process with links to where I got info here, partly in order to get feedback if it’s wrong!

With ssh it’s just a matter of copying the contents of your .ssh directory – which contain the public and encrypted private key. The android keys are in a file called .keystore, in your home directory.

When it comes to GPG the best way seems to be to list and export them individually with:

gpg --list-secret-keys
gpg --export-secret-keys your-id-number > secret-key.asc

The id number is the part after the slash for each keypair. At the same time, it’s important to back up a revocation key for each key – this allows you to tell the GPG trust network if your identity becomes compromised by someone finding out your key (or losing/forgetting your passphrase, which is perhaps more likely). You can do this with:

gpg --gen-revoke your-id-number

And paste the result into a text file.

So you can take all these files and store them somewhere safe on a usb stick for example. It all needs to be encrypted so it doesn’t matter if it’s found and accessed. I almost made a fundamental mistake and encrypted it with GPG, which would have been like locking my house keys inside the house. Instead you can encrypt the file using AES independently using this command:

openssl aes-256-cbc -in your-key-file.tar.gz -out your-key-file.tar.gz.enc

I’m assuming once this is done, the best practice is to put it in various places to reduce the chances of it getting lost, as it doesn’t matter if it’s accessible. Make sure to use a long passphrase you won’t forget! The advice given here is to use a long randomly generated string and write it on a piece of paper, which is stored in a safety deposit box – this is the approach to take if you are in charge of really important stuff, I’m not sure that I’m at that point yet :)