Yearly Archives: 2018

Party Gopher!

June 13, 2018 » Geek

The Go slack has a cute little dancing Gopher that appears to have come from Egon Elbre. I love it!

Dancing Gopher

This little dancing Gopher made me think of Party Parrot, so I wanted to parrot-ize him. Normally I might just open up Gimp and start editing, but this is the Go Gopher, we can do better than that!

My plan was to use Go’s image packages to edit each frame and replace the blue with the correct parrot color for that frame by walking over the pixels in each frame.

Once I got into the package docs however, I realized that since gif’s are paletted, I can just tweak the palette on each frame and be done. Much simpler. Let’s get into then, shall we?

Colors!

First things first, I needed to declare the party parrot frame colors, and the light and dark blue that the dancing gopher uses. I grabbed the blues with Sip and I already had the parrot colors on hand. Sure, I could precompute these and declare, but let’s keep it interesting.

Note that I have a DarkParrotColors slice as well, this is for the corresponding dark blue replacements. I generate these with darken which I’ll show in a moment.

Also notable is the hexToColor which just unpacks an HTML hex RGB representation into a color.Color.

Here is the darken function, pretty simple.

Now I need to pull in the gif and decode it, all very boilerplate.

After that, I iterate over the frames and edit the palettes.

Lastly, more boilerplate to write it out to disk.

Party Gopher

You can grab the code on Github, and thanks again to Egon Elbre for the excellent original gif!

A New GPG Key

May 30, 2018 » Geek

It’s been 12 years since I created my first GPG key and 11 since I’ve created the one I actually use. That is far too long, so I decided to create a new pair and deprecate the old. In 2013 I started this process, but I didn’t follow through and I’ve since lost access to those keys. I know where they are, but the machine died so I need to hook up it’s HDD and pull the keys out.

Regardless, it is time for new ones, and I did some reading to get a real plan for this. I would generate a new, strong key offline, with a subkey for each capability. The subkeys would go onto a smart card, in my case a Yubikey 4. The primary key material would go to offline backup to keep it safe.

Disclaimer

Nothing in this post is new or novel, but rather collected from many other posts. I’ve tried to link to any relevant posts below each section, and I encourage you to read these sources. Any mistakes I’ve made I would be glad if you send me an email (GPG encrypted of course ;) to point it out.

Yubikey Configuration

After I ordered my Yubikey, I had to configure it. The Yubikey docs expect a fair amount of knowledge before you start, but the steps are pretty simple when you understand it. Basically, it boils down to:

  1. Change the Admin PIN
  2. Change the PIN
  3. Set a Reset Code
  4. Fill in optional metadata

Plug in your card and proceed as follows:

Links

Generating Keys

Next, I created my keys. Be sure you set up a clean environment for this, ideally a random directory in /tmp, better still on a ramfs of an offline, live CD machine. But that’s a bit drastic for my use case.

You’ll want a good base config file in there too.

With the directory in place, I can create a primary key, option 4. 4096-bits is as strong as GPG allows right now, and I set it not to expire because I will be keeping offline and it should be ok to revoke manually if needed.

Now it’s time to create subkeys. There are four capabilities that a PGP key can have.

C is for Certify

Your primary key will have the capability of Certification. Certify is essentially the ability to sign other keys. A key with Certify can be “parent” to subkeys, create new subkeys, and edit existing ones. You also need this capability to sign another users public key.

S is for Sign

A key with the Sign capability can sign files and messages, allowing others to verify their integrity.

E is for Encrypt

A key with the Encrypt capability is used for encrypting files. Simple.

A is for Authenticate

An Authentication key is generally used for SSH authentication.


Generating the subkeys is a bit tedious, but so it goes.

The authentication key requires E X P E R T M O D E. Git gud.

That’s it! We’re in business.

Links
  1. https://spin.atomicobject.com/2013/11/24/secure-gpg-keys-guide/
  2. https://www.linode.com/docs/security/authentication/gpg-key-for-ssh-authentication/
  3. https://gist.github.com/abeluck/3383449
  4. https://alexcabal.com/creating-the-perfect-gpg-keypair/
  5. https://gist.github.com/graffen/37eaa2332ee7e584bfda

Backups

Before we do anything else, we need to back that thang up.

I’m choosing two methods: backup to a USB key that will live in a fire safe (who has a safety deposit box these days?), and a printed backup in case the USB key fails. Ideally these two articles would not be co-located.

First we export the keys and move them to the USB stick. The export-secret-subkeys output is less important than the export-secret-key output as it doesn’t contain a viable certification key, but would be useful as a “middle tier” of backup that wouldn’t expose your primary key to risk.

Now, we could take these ascii armored keys and just print them, but that’s a lot of bytes to pray for OCR to recognize. Instead, we can use a piece of software called Paperkey which strips out everything but the most secret parts of the key and gives you something much shorter to type in.

Still not fun to type it all in, but it’s better and this is a last ditch sort of thing anyway.

Recovery

Backups you don’t test aren’t backups, they are hopes and dreams. So let’s try recovering from our paperkey output!

Links
  1. http://www.jabberwocky.com/software/paperkey/

The certificate revoke you, secret key!

While not required, we can generate a revocation certificate while we still have the primary key on this machine.

Throw that onto your backup drive too while you’re at it.

Links
  1. https://www.hackdiary.com/2004/01/18/revoking-a-gpg-key/

Sign!

Ok. Everything is generated, we have a good backup, we are ready to transition. To indicate that this key is your new key, you can sign it with your old one, then send it up to the keyservers in the sky (if you’re into that)

Links
  1. https://www.apache.org/dev/key-transition.html

To The Smart Card Robin!

I'm Batman

Moving the keys onto a smart card helps protect them. They won’t exist on your filesystem anymore, only on the card. That means they can’t be read out and stolen by a malicious process, but you can still use them by providing your smart card pin and key password.

Keep in mind, this is a one way trip. Make sure your backups are really, truly in place. We want to move our Signing, Encryption and Authentication keys onto the card. The Certification key we will only store offline, as mentioned before.

HOYB

Hold onto your butts.

This is it. The big moment. Take out that smart card, secure your backups, and let’s delete our primary key material.

Now you can have gpg create key stubs for all the keys on your smart card.

Now when we list keys, we see that our primary key has a # next to it, showing we don’t have access to that secret key. The subkeys have a > next to them showing they are stubs for the keys on the smart card. Success!

Fin!

That’s it. There is, of course, more to do, like setting up git signing, SSH access, etc. But the new keypair is created, and it’s on the Yubikey, so that’s all for now.


Update: Git Signing

Turns out git signing is a cinch. Just throw a couple items into your git config and it’s automatic and transparent.

user.signingKey

Tells git which key to use for signing, unset it just uses the default key.

commit.gpgSign

Makes it sign all commits by default, instead of passing -S to every git commit.

log.showSignature

By default, git won’t show you if a commit is GPG signed. You can see it with gpg log --show-signature, or you can set it as default with this config option.

It makes signed commits much chunkier, so be aware of the reduced screen real estate.

merge.verifySignatures

This is the only one I am not setting by default. If you have it enabled, all merges that include unsigned commits will be rejected. This really only works if everyone in your organization is signing all their commits.

Links
  1. https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
  2. https://git-scm.com/docs/git-config

Update: One-Touch Actions

By default, with the smart card in, GPG will happily sign and decrypt things after you enter your PIN the first time, with no further interaction from you. The Yubikey offers a mode where these actions require a touch on the key to complete, which I like because it makes the action more explicit without requiring me to remove the key between operations.

To enable this, you need a special script, yubitouch.sh. To make it work with my GPG Tools install, I had to hard code the path to gpg-connect-agent (/usr/local/MacGPG2/bin/gpg-connect-agent) and my admin PIN, since pinentry wasn’t working and I didn’t want it in my bash history.

Now, when GPG needs to sign something, my Yubikey flashes at me until I touch it and give my permission. Neat.

Links
  1. https://developers.yubico.com/PGP/Card_edit.html
  2. https://github.com/a-dma/yubitouch
Tags: , ,

Chicken Cam: Incubator Edition

March 4, 2018 » Geek, Life

It’s been over a year since we’ve had chickens and we’ve missed them, so this Christmas we got Lizzy and Charlotte an incubator so that we could try hatching some this spring.

When we went to purchase eggs, we found that you could most easily get them 10 at a time from the hatchery we have used in the past, Murray McMurray. Since the incubator we got the girls could only hold seven, we would need something for the other three. Some searching found that you could use a styrofoam cooler and a lamp to create a makeshift incubator, so I planned on that.

Once I had a plan to create an incubator, I knew I would have to overcomplicate things. Four years ago I built a webcam for our chicks so I figured I would do that this time too. Also, just setting a lamp and thermometer in and hoping for the best seemed like a potential waste of good eggs, so I wanted to monitor the temperature and humidity, and regulate them.

My initial design was a Raspberry Pi connected to a cheap DHT11 temperature and humidity sensor, controlling a relay that could turn the light on and off. All of it would be hooked up through a PID controller to keep the temperatures right where we want them. Eventually, I added a thermocouple with a MAX6675 for more accurate temperature readings.

Raspberry Pi, Relay and a mess of wires.

The server side would be designed similarly to the previous chicken cam, except written in Go. The stats would be tracked in InfluxDB and Grafana would be used for viewing them.

After I got all the parts I did a little testing, then soldered things up and tested it to see how it ran.

Initially I wrote everything in Go, but the DHT11 reading was very spotty. Sometimes it would respond once every few seconds, and sometimes it would go a minute or more failing to read. I wired on a second DHT11 and tried reading from both, but I didn’t get that much better performance.

Eventually I tried them from the Adafruit Python library and had much better luck, so I decided to just read those from Python and send them to my main Go application for consumption. I still have trouble with the DHT11’s, but I suspect it’s my fault more than the sensors fault.

My next issue was that it was extremely jittery, the readings would vary by degrees one second to another, so I collected readings in batches of 5 seconds then averaged them. That smoothed it out enough that graphs looked reasonable.

On. Off. On. Off. On. Off.

Temperature was now well regulated, but the air wasn’t humid enough. I switched to a sponge and found I could manage it much easier that way. I briefly tried a 40W bulb thinking I could spend more time with the lamp off, but temperatures still plunged at the same rate when the light was off, so I mostly just created quicker cycles.

After putting the 25W bulb back in, I still wanted a longer, smoother cycle, so I wrapped up a brick (for cleanliness) and stuck that in there. That got me longer cycles with better recovery at the bottom, it didn’t get too cold before the lamp came back on. Some slight improvements to the seal of my lid helped as well. I had trouble with condensation and too much humidity, but some vent holes and better water management took care of that.

Before the brick.

After the brick.

For the server side, I mostly duplicated the code from the previous Chicken cam, but in Go. Then I used the InfluxDB library to get the most recent temperature and humidity readings for display.

At this point, I felt ready for the eggs, which was good because they had arrived! We placed them in the incubator and we’re just waiting now. On day 8 we candled them with a homebuilt lamp i.e. a cardboard box with a hole cut in it.

Candling

Things seem to be progressing well so far, so here’s hoping something hatches!