The second concert I ever attended was Alice Cooper, on the Raise Your Fist and Yell tour. I was thirteen years old. I wasn't at that time a fan of Alice Cooper, but I was familiar enough with the theatrics of his work to know that I wanted to see him when the show came to town. I convinced my parents to take my friend Devin and me.
I remember being nervous around all of the large, black-clad fans milling around before the show. I remember being scared of the guy down the row from me smoking a joint. I remember the opening act, Frehley's Comet, led by former KISS lead guitarist Ace Frehley. I remember only some of Cooper's on-stage fright show, but I do remember enjoying it. I don't remember any of the music.
That concert made me an Alice Cooper fan, though, and I've enjoyed his works ever since. I've enjoyed his various cameos, and I've long wished for an opportunity to see him perform live again.
That desire came true last night.
There was no opening act, so the concert was two solid hours of Alice Cooper performing some of his greatest hits. The show opened with Vincent Price's monologue for "The Black Widow", and then the first part of that song was played before transitioning to another song I unfortunately didn't know. There were only two songs in the whole evening with which I had no familiarity. "Under My Wheels" was played very early in the evening, as was "Billion Dollar Babies". A few songs I didn't expect made it into the lineup, including "Is It My Body," "Poison," and "Cold Ethyl".
And of course there were theatrics. There were plenty of electric sparks, scary characters, a live snake, a 12' tall monster running around the stage, and the guillotine, which severed Cooper's head and shot blood out onto the audience.
The band was great, and full of energy. They were every bit the showmen that Cooper was, making for a great show to watch as well as to listen. Cooper didn't run around the stage, and he wasn't screaming his vocals out. He gave a solid, enduring performance and knew, from years of experience, exactly how to work the crowd. I had a grin on my face the entire time because I was having so much fun.
The audience was as interesting as the show. A lot of aging rockers, many of them worse for the wear. There weren't too many teens, but there were a surprising number of adolescents and family groups. It was nice to see parents taking their kids to the show. Everyone that I saw appeared to be having as much fun as I was.
The band played four tributes to departed rock heroes, one song each from Keith Moon, Jim Morrison, Jimi Hendrix, and David Bowie. All four songs were beautifully performed, and the crowd ate it up. The band closed with "Eighteen", and did a single encore of "Elected".
During the song, Cooper introduced "the candidates" and two performers in Trump and Clinton masks came out and monkeyed around for a bit. This was the only part of the show I didn't like. It wasn't an overtly political statement, but I felt it was a distraction from what I came to watch. It was clownish and silly, and not in the same tone as the rest of the theatrics of the show.
Like the first time I saw Alice Cooper, there were still plenty of large, black-clad fans. And there were a lot of people smoking joints. I kept looking to see a wide-eyed teenager experiencing his second concert, but that kid never showed up.
I've had skippy.net for almost two decades. This site has experienced a number of transformations in that time. I've spent a lot of time looking for a visual presentation that I like. My tastes have changed over the years. I've spent a lot of time mucking around with CSS, divs and spans, and color choices.
None of those things are why I chose, way back when, to host a blog. I have a blog to share my thoughts with the world. The contents of the blog are the thing, not the way the blog looks. I'm not trying to impress anyone with the presentation of my thoughts, so why was I spending so much time fiddling with CSS?
To that end, I've completely abandoned any kind of visual styling, relying solely on plain HTML. The primary "reader" of this site is googlebot, which doesn't give a wet slap about pixel alignment, color choices, or fonts. Presumably some portion of human readers are using a feed reader of some sort, so any effort at a beautiful design are rendered moot. And for everyone else visiting this site the old fashioned way, they're not losing out on any kind of "experience".
I've been composing all of my emails in plaintext for years. Plaintext is easy to deal with. It's easy to copy and paste. It's machine readable. The same benefits hold true for this site. Why is my computer sending your computer a bunch of extra information about how to present my words? Why am I worrying about browser incompatibilities, nuances of mobile, or anything else? Your web browser, regardless of platform, knows how to render headers, images, and hyperlinks. If you want the font to be larger or smaller that's your choice, not mine.
I certainly appreciate a well crafted site. I admire those who can bend CSS to their will, and who work hard to build a beautiful experience. That's not me, though, so I'm going to focus on words again.
Some people have very strong feelings about the nature and the content of the Second Amendment to the Constitution of the United States. I do not currently have strong feelings about this amendment. I have never owned a firearm, so this right afforded to me has always been an intellectual one, rather than a practical one. As such, any modifications to the Second Amendment will have very little bearing on my day-to-day life.
A thought experiment recently occurred to me, though.
Imagine that a new constitutional amendment were to pass, either by two-thirds vote of all members of the House and Senate, or by two-thirds vote at a national convention, that substantially limited personal ownership of firearms. Would you support that amendment as the rule of law?
As a thought experiment, much is left out by design. Of course the specific nature of the changes imposed by the new amendment, and its implementation details, would effect how one feels about it. The thought experiment is not asking how you feel, but whether you would adhere to the Constitutional process and submit to the will of the people.
I can't begin to imagine how slave owners felt at the passage of the Thirteenth Amendment, knowing that one day a cultural (and commercial) institution was legal and the next day it wasn't. There's no doubt that many slave owners rejected the legality of the amendment. There were a lot of creative maneuvers executed after passage of the Thirteenth Amendment to preserve the previous status quo as much as possible, making every effort to subvert the spirit of the law.
I wonder what lessons we might learn from the Thirteenth Amendment about any potential changes to the Second Amendment.
Long time reader Bob O. sent the following (unencrypted) question to me in response to my GnuPG + mutt + OSX + GMail article:
Question on your GPG article: The paragraph on why you don't install your
private key on your mobile or home devices seems to imply that you have
better physical security on your work laptop than those devices. I realize
that this opens the article up to a discussion of how to secure your
private key, but could you add a brief overview of your choices on where to
store your private key?
This is an excellent question, and I did gloss over it in my original post.
My mobile phone is not currently encrypted, though I have thought about enabling that feature. Even if my mobile phone were fully encrypted, I'm still pretty suspicious of both Android and iOS against covert attacks from government actors. The Snowden revelations indicate that NSA, GCHQ, and potentially others have found very subtle ways to compromise a mobile phone without physical access to the device.
I could keep my private keys on a device at my house, but I'd have no real way of knowing if any of those devices were physically attacked in my absence. I realize it's unlikely that someone would break into my house for the sole purpose of accessing my GnuPG private key, but this seems like an easy precaution to take. The media on a Raspberry Pi is simply an SD card or external HDD, both of which would be easy to make copies of and then reconnect. Similarly, I don't keep my private key on my server at DigitalOcean because I have no way of knowing if the virtual machine had been cloned.
(Even absent a specific effort to obtain my GnuPG private key, the physical loss of a device containing said private key should necessitate a revocation of my public key. There's simply no good way to know if the private key was compromised or not.)
My work laptop is usually with me. It's a unibody MacBook, so it's not easy to access the hard drive directly (though I admit to ignorance as to whether there are easy ways to clone the hard drive without removing it). It also employs full disk encryption, so none of the data on the device is (easily) available to anyone who might gain access to it. OSX is not immune to malware, but it is fairly resistant to it, in general. If an actor were able to compromise my work laptop by way of specially crafted malware, there's little I could do: I don't think I'm quite paranoid enough to spot (or react to) a custom attack against me, whereas I am savvy enough to spot (most of) the general kinds of malware looking for easy marks.
So while I do think OSX may have some security advantages over my mobile phone, it's more a matter of limiting the exposure of my private key to the minimum number of devices that makes practical sense.
I do use a complex password for my private key, but if someone has access to a copy of my private key then they can attack it all day long. They can run through every permutation of every possible password until they get access. It might be time consuming, and it might be expensive, but eventually the key will be cracked.
This password for my private key is not stored in my password manager, and to the best of my knowledge not written down anywhere. By using the GPG agent I can avoid repeated entry of my private key password. This reduces, but does not eliminate, the risk of keyloggers.
There are additional things I can (and may) do to further enhance my security. I do not currently have an expiration on my GnuPG key. I should set one, and take the time to extend that expiration as needed, as long as my key hasn't been compromised. I should also generate a revocation certificate.
I don't believe that I'm the target of government (or other) surveillance, so extreme paranoia is not driving most of my decision making. Nonetheless, I'm trying to take reasonable precautions to protect my private key from easy exploitation. I do have an offline backup of my private key stored securely, in case my work laptop suffers a catastrophic failure. Hopefully I'll never need to use it.
A little over two years ago I generated a new GnuPG key. I had been using a 1024-bit key created in 2004, so I created a new 4096-bit key. I've used this new key only a handful of times since it's creation.
In early 2014 I joined Keybase with high hopes of seeing an increase in GnuPG adoption. A few folks I know use the service, and we've cross-validated one another; but none of them have sent me any encrypted messages. Of course, Keybase's larger utility is as much in "proving" my various online identities as it is in facilitating encryption.
At the 2015 Ohio LinuxFest, one of the birds-of-a-feather sessions was a keysigning party. There were about a dozen of us in attendance, some complete novices and some GnuPG experts. It was a great opportunity to meet a few new folks, as well as pick up a few GnuPG best practices.
All of this took place shortly after I declared my intention to learn mutt for my day-to-day email usage. Mutt has great support for GnuPG, and I was hopeful that this support would encourage me to use GnuPG as much as mutt.
I've learned rather a lot in the last couple of weeks, and this post is an effort to record and share some of that information for others. Aside from a few OSX specific bits, most of what follows should be generally applicable to Linux users as well.
All of what follows is my own opinion. You likely don't know me, so you should not trust my opinion. Do your own research, and figure out what settings make sense for you! If you find any factual inaccuracies in my suggestions, please contact me and let me know!
I've been using OSX exclusively for my day-to-day desktop computer use. (My employer has a few compliance requirements not yet easily satisfied by Linux, so this is as close as I can get to a POSIX-based system.) There are two ways to install GnuPG onto an OSX system: Homebrew or GPG Suite. I chose the latter, because it provides good Finder and Mail.app integration, but these are conveniences only.
The default options for GnuPG are okay, but not great. Depending on your level of paranoia, the defaults may be downright disastrous. One of the more interesting documents I found was Operational PGP, which was chock full of usefully paranoid suggestions. That, combined with OpenPGP Best Practices provided the bulk of my
In particular, ensure that you're not using old and insecure algorithms:
cert-digest-algo SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed personal-cipher-preferences AES256 AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 SHA224
Also ensure that you're not leaking information unnecessarily:
no-greeting no-comments no-emit-version throw-keyids
When using GPG Suite on OSX, be sure to make use of the GPG agent:
The agent makes it much less hassle to use GnuPG. And it will come in particularly handy with mutt, too!
There was some interesting disagreement after the Ohio LinuxFest keysigning party with respect to proper next steps. Do you encrypt the signed key that you send? Do you individually sign each user ID on a public key? Do you push to keyservers? Each keysigning party may have different norms, so be sure to get answers to these questions before taking any actions! The Debian keysigning instructions may be useful as a reference for possible best practices.
GNU/Linux users are encouraged to use caff, which handles much of the tedium of signing and sending signatures to the folks at a keysigning party. Unfortunately, caff doesn't work on OSX (despite being in homebrew). Additionally, caff sends mail directly from the host on which it is invoked, which may not work for laptops connected to residential ISPs. You may need to correctly configure a relay host in order to make the most of caff.
Once you have GnuPG configured, take a look at pass, a GnuPG based password management system for Linux and OSX. pass works well for individuals as well as groups. We use it at work, and it's proven extremely helpful.
Installing mutt on OSX is best accomplished with Homebrew:
brew install mutt was my first attempt, and this does work well enough. But this default incantation leaves out a newer feature of mutt's GnuPG support: GPG Made Easy (GPGME). GPGME allows you to drastically simplify your mutt config file with respect to GnuPG. In order to get mutt to use GPGME, you need to manually compile it:
brew install mutt --build-from-source --with-gpgme --with-slang
With GPGME, the relevant section of my
.muttrc file is this:
set pgp_autosign=no set pgp_auto_decode=yes set pgp_sign_as="0xD8F2E57BED0F2C0A" set pgp_replysign=yes set pgp_replyencrypt=yes set pgp_timeout=1800 set pgp_use_gpg_agent=yes set crypt_use_gpgme=yes set crypt_replyencrypt=yes set crypt_replysignencrypted=yes set crypt_verify_sig=yes
I realize that looks like a lot, but compare it with the recommendations from the mutt wiki.
If you're a GMail user, you can use something like the following to get mutt to connect:
set imap_user = "firstname.lastname@example.org" set imap_keepalive=60 set imap_passive=no set imap_check_subscribed=yes set imap_idle=yes set mail_check=60 set smtp_url = "smtp://email@example.com@smtp.gmail.com:587/" set from = "firstname.lastname@example.org" set smtp_authenticators = 'login' set folder = "imaps://imap.gmail.com:993" set spoolfile = "+INBOX" set postponed ="+[Gmail]/Drafts" set record="+[Gmail]/Sent Mail"
OSX users: take particular note of the
set smtp_authenticators directive. This resolves a bug with the homebrew formula for mutt. I was unable to login without this.
I don't want to type in my GMail password every time I connect, and I don't really want to leave a plaintext copy of my GMail password in my
.muttrc. Since I'm using GPG and the GPG agent, I can encrypt my password and decrypt that on the fly when mutt starts!
source "gpg -d ~/.mutt/passwords.gpg |"
For lots of other great suggestions about dealing with GMail, check out GPG / Mutt / Gmail by Ben Nagy. I particularly liked the recommendations for SSL hardening, and not blindly trusting SSL certs presented by IMAP and SMTP servers.
It's been a fun adventure learning some of the intricacies around GnuPG, mutt, and GMail. The fact that I'm using OSX does tend to complicate things, since so many howtos online are written for GNU/Linux users.
I still use the GMail web interface with depressing frequency, despite all the effort to configure and learn mutt. I'm trying hard to use mutt exclusively, but that's quite an uphill battle.
One of the interesting things that all of the above work does not address is shared access to my Inbox from my laptop and my mobile phone. I will not install my GnuPG private key onto my mobile phone, so any encrypted emails I may receive will need to lie unread until I can access them on my laptop. Similarly, I won't install my private key onto my VPS server, or a Raspberry Pi at home, or any other device I'm not likely to have in my immediate possession at most times.
UPDATE: I discuss private key security in a subsequent post.
So far this hasn't been an issue, given the paucity of encrypted emails I receive. If encrypted emails were to become more commonplace for me, I might need to revisit my policy against my private key on my phone, since my phone is where I read the surprising majority of my emails these days.
home / contact / flickr / github / keybase / linkedin / twitter
The contents of skippy are licensed under a Creative Commons Attribution 4.0 International License.