commit 94db0a9581000617d0354f7b484ea433376c096a
parent 9329e48c350d39520d70939661877913ad2f39c2
Author: Jake Bauer <jbauer@paritybit.ca>
Date: Sun, 17 May 2020 23:53:47 -0400
Publish new blog post
Diffstat:
5 files changed, 426 insertions(+), 2 deletions(-)
diff --git a/pages/blog.md b/pages/blog.md
@@ -20,6 +20,7 @@ href="https://social.paritybit.ca/@jbauer">Mastodon</a>.
### 2020
<ul>
+ <li>2020-05-17 <a href="blog/setting-up-gpg-keys-from-scratch">Setting Up GPG Keys from Scratch</a></li>
<li>2020-05-16 <a href="blog/self-hosting-email">Self-Hosting Email</a></li>
<li>2020-05-15 <a href="blog/preparing-to-self-host-email">Preparing to Self-Host Email</a></li>
<li>2020-05-13 <a href="blog/diving-deeper-into-the-small-internet">Diving Deeper Into the Small Internet</a></li>
diff --git a/pages/blog/setting-up-gpg-keys-from-scratch.md b/pages/blog/setting-up-gpg-keys-from-scratch.md
@@ -0,0 +1,211 @@
+## Setting Up GPG Keys from Scratch
+
+[//]: # "How I set up my GPG keys from scratch and how I manage them."
+
+[//]: # "main.min.css"
+
+[//]: # "Introduction; Generating the Master Key; Generating a Revocation Certificate; Generating Subkeys; Going Backup Crazy; Uploading My Keys to a Keyserver; Configuring GPG and GPG-Agent; Deleting My Master Key; Conclusion;"
+
+<div class="byline">
+<b>Written By:</b> Jake Bauer |
+ <b>Posted:</b> 2020-05-17 |
+ <b>Last Updated:</b> 2020-05-17
+</div>
+
+### Introduction
+
+_**Disclaimer:** This isn't really supposed to be a comprehensive guide on how
+you should set up GPG, it's more a record of what I did and why. This post will
+inevitably become outdated in the future so please use good judgement when it
+comes to your security._
+
+Now that I'm self-hosting mail and moving off of ProtonMail, I figured I need to
+actually properly figure out GPG so I can send and receive encrypted emails. It
+will also be essential as I get further involved in free and open source
+software development since GPG is commonly used to sign software releases, among
+other things.
+
+GPG is notorious for being quite complicated and not user-friendly. To assist in
+my GPG adventures, I enlisted the help of the Internet; mainly [the Arch
+wiki](https://wiki.archlinux.org/index.php/GnuPG).
+
+I previously played around with GPG so I could use it for encrypting local
+backups and for signing git commits. I wasn't using it seriously in any other
+respect so I began by `rm -rf`ing my `~/.gnupg` directory for a fresh start. I
+also set the `GNUPGHOME` environment variable to a directory on the SD card
+which I use specifically to store key data. On this SD card are key files, SSH
+keys, and now GPG keys all under LUKS encryption (don't worry, I keep many
+copies of this SD card on other cards, USB sticks, and hard drives). Having a
+separate portable medium for my keys makes it so that I only have to worry about
+updating what's on the card instead of what's on all of the machines on which I
+am using GPG. It's also technically a lot easier to hide or destroy, but I don't
+see myself realistically needing to do that.
+
+### Generating the Master Key
+
+Generating the master key is pretty straightforward.
+
+<pre><code>$ gpg --full-gen-key --expert
+</code></pre>
+
+`--expert` is required because I wanted to use [Elliptic Curve
+Cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography)
+(`ed25519` keys in particular) instead of RSA since ECC keys are smaller for a
+similar level of security. From the article linked above: "a 256-bit elliptic
+curve public key should provide comparable security to a 3072-bit RSA public
+key". This will make typing in the key a lot easier and less error-prone should
+I have to restore it from paper backups. It's also fewer bits to send over the
+Internet when sharing my public keys.
+
+### Generating a Revocation Certificate
+
+It's very important to have a revocation certificate since it's what one
+publishes if their key is ever compromised or otherwise needs to be revoked.
+It's essentially a way for one to tell the world "under no circumstances should
+you use or trust this key." Unlike with subkeys, revoking a master key is much
+more significant since, once that becomes compromised or lost, one has to start
+again from scratch.
+
+<pre><code>$ gpg --gen-revoke --armor --output=revocation-certificate.asc <user-id>
+</code></pre>
+
+Where `<user-id>` in this case is the email I specified when generating my key:
+`jbauer@paritybit.ca`.
+
+### Generating Subkeys
+
+Typically, one shouldn't be using their master key for every-day use. That's
+because one's master key is used for signing others' keys, issuing new keys, and
+it's the ultimate representation of one's GPG identity. Instead, one should use
+subkeys as it's far easier to revoke them and issue new ones in the case that
+they become compromised.
+
+I generated one subkey specifically for signing and one subkey specifically for
+encryption:
+
+<pre><code>$ gpg --edit-key --expert jbauer@paritybit.ca
+>addkey
+</code></pre>
+
+I also set a one month expiry on both of those subkeys. While I think having an
+expiring master key is overkill for my uses and would be too much hassle, having
+subkeys expire is useful in the case that access to those subkeys is lost. This
+allows me to be less neurotic about backing up my subkeys compared to backing up
+my master key.
+
+I chose a length of one month because it will keep me coming back to GPG
+regularly. This way, I can both make sure that my master key backups have not
+become corrupted without my knowledge and that I keep my GPG skills honed. It
+also gets me in the habit of doing monthly maintenance on my keyring.
+
+### Going Backup Crazy
+
+To make sure that my master key and revocation certificate stay as private as
+possible and to minimize the risk of me ever losing access to them, I went a
+little bit crazy with the number of backup copies I made.
+
+It's extremely important to have physical copies of both because digital media
+can fail over time in ways that are hard to detect until one needs to access the
+data. I printed my revocation certificate directly since it's just a short bit
+of ascii text and I printed out my master key using `paperkey`. Both of these
+pieces of paper went into my fire- and water-proof storage bag.
+
+<pre><code>$ gpg --export-secret-key jbauer@paritybit.ca > privkey.gpg
+$ paperkey --secret-key privkey.gpg --output printed.txt
+$ lpr printed.txt
+$ rm privkey.gpg printed.txt
+</code></pre>
+
+I also made several digital copies of my private key. First, I exported my
+master key using:
+
+<pre><code>$ gpg --export-secret-keys --armor jbauer@paritybit.ca > master.asc
+</code></pre>
+
+Then, using GPG's symmetric encryption capabilities, I encrypted both it and my
+revocation certificate using a completely new, randomly generated passphrase:
+
+<pre><code>$ gpg -c master.asc
+$ gpg -c revocation-certificate.asc
+$ rm master.asc revocation-certificate.asc
+</code></pre>
+
+I then put both of the new encrypted files: `master.asc.gpg` and
+`revocation-certificate.asc.gpg` onto two separate CDs—one went into my
+fireproof bag—and onto a floppy disk which also went into my fireproof bag. As
+soon as I have a free USB key, I'll be making a copy on that too.
+
+### Uploading My Keys to a Keyserver
+
+Using a keyserver allows for both easier access to my public keys for others as
+well as convenient offsite storage for the public part of my master key which is
+required to restore the private part of my master key using `paperkey`. A while
+back, [an attack on the SKS keyserver network was
+discovered](https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f)
+which caused many to become apprehensive about using keyservers. A solution
+proposed in the linked article was to use
+[keys.openpgp.org](https://keys.openpgp.org) which is a new keyserver designed
+to mitigate the issues with the old keyservers. Following the [given
+instructions](https://keys.openpgp.org/about/usage), I uploaded my public keys
+so others should now be able to find me by searching for my email. Any time I
+need to use my master key (e.g. to sign another's key or renew my subkeys), I
+can re-sync my public keys with the keyserver so they always stay up to date in
+others' keyrings.
+
+### Configuring GPG and GPG-Agent
+
+This is pretty simple and straightforward. Taking a few notes from the Arch wiki
+and setting options that I wanted to avoid having to type each time I ran `gpg`,
+I came up with the following configuration files:
+
+<pre><code>gpg.conf
+--------
+keyserver hkps://keys.openpgp.org
+keyid-format long
+with-fingerprint
+with-subkey-fingerprint
+personal-digest-preferences SHA512
+cert-digest-algo SHA512
+default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
+</code></pre>
+
+<pre><code>gpg-agent.conf
+--------------
+# Cache for a day
+max-cache-ttl 86400
+default-cache-ttl 86400
+# Use curses-based pinentry program
+pinentry-program /usr/bin/pinentry-curses
+</code></pre>
+
+### Deleting My Master Key
+
+All of that backing up and making offline copies of my master key is so that I
+can do daily tasks with just my subkeys. To make this make sense, I have to
+delete my master key out of my keyring so it only exists offline until I need to
+use it. Since GnuPGv2.1, this is fairly straightforward:
+
+<pre><code>$ gpg --list-keys --with-keygrip
+$ rm /media/jbauer/keys/gpg/private-keys-v1.d/<keygrip>.key
+</code></pre>
+
+After decrypting it from one of my backups, I can then later restore this key
+(which I'll have to do at least once a month) by re-importing it with:
+
+<pre><code>$ gpg --import master.asc
+</code></pre>
+
+### Conclusion
+
+Without a doubt, using GPG is quite complicated. There are a variety of
+decisions that one can make depending on their desired level of security or
+anonymity which can be overwhelming if one doesn't have much experience. I've
+spent probably 3 or 4 hours making sure that my processes are sound and making
+sure I'm doing everything right. To be honest, since I'm relatively new to using
+GPG seriously, I won't be 100% sure I'm doing things right until I can
+experience using it in the real world.
+
+_This is my twenty-second post for the
+[#100DaysToOffload](https://social.paritybit.ca/tags/100DaysToOffload)
+challenge. You can learn more about this challenge over at
+[https://100daystooffload.com](https://100daystooffload.com)._
diff --git a/pages/home.md b/pages/home.md
@@ -20,6 +20,8 @@ extent)! Access through `gopher://paritybit.ca` or `gemini://paritybit.ca`.
src="/img/feed-icon.png" width="15" height="15" alt="Click for RSS Feed"/>
</a>
</div>
+2020-05-17 <a class="feed-item" href="blog/setting-up-gpg-keys-from-scratch">Setting Up GPG Keys from Scratch</a>
+
2020-05-16 <a class="feed-item" href="blog/self-hosting-email">Self-Hosting Email</a>
2020-05-15 <a class="feed-item" href="blog/preparing-to-self-host-email">Preparing to Self-Host Email</a>
@@ -38,8 +40,6 @@ extent)! Access through `gopher://paritybit.ca` or `gemini://paritybit.ca`.
2020-05-07 <a class="feed-item" href="blog/unsure-what-to-write">Unsure What To Write</a>
-2020-05-07 <a class="feed-item" href="blog/the-joys-of-old-tech">The Joys of Old Tech</a>
-
### What is a Parity Bit?
It is a bit (in the 1's and 0's sense) used in checking for errors in digital
diff --git a/public/feeds/sitewide-feed.xml b/public/feeds/sitewide-feed.xml
@@ -7,6 +7,217 @@
<description>The feed that covers all notable additions, updates, announcements,
and other changes for the entire paritybit.ca website.</description>
<item>
+ <title>Setting Up GPG Keys from Scratch</title>
+ <link>https://www.paritybit.ca/blog/setting-up-gpg-keys-from-scratch</link>
+ <guid>https://www.paritybit.ca/blog/setting-up-gpg-keys-from-scratch</guid>
+ <pubDate>Sun, 17 May 2020 23:53:09 -0400</pubDate>
+<description><![CDATA[<h2>Setting Up GPG Keys from Scratch</h2>
+
+<div class="byline">
+<b>Written By:</b> Jake Bauer |
+ <b>Posted:</b> 2020-05-17 |
+ <b>Last Updated:</b> 2020-05-17
+</div>
+
+<h3>Introduction</h3>
+
+<p><em><strong>Disclaimer:</strong> This isn't really supposed to be a comprehensive guide on how
+you should set up GPG, it's more a record of what I did and why. This post will
+inevitably become outdated in the future so please use good judgement when it
+comes to your security.</em></p>
+
+<p>Now that I'm self-hosting mail and moving off of ProtonMail, I figured I need to
+actually properly figure out GPG so I can send and receive encrypted emails. It
+will also be essential as I get further involved in free and open source
+software development since GPG is commonly used to sign software releases, among
+other things.</p>
+
+<p>GPG is notorious for being quite complicated and not user-friendly. To assist in
+my GPG adventures, I enlisted the help of the Internet; mainly <a href="https://wiki.archlinux.org/index.php/GnuPG">the Arch
+wiki</a>.</p>
+
+<p>I previously played around with GPG so I could use it for encrypting local
+backups and for signing git commits. I wasn't using it seriously in any other
+respect so I began by <code>rm -rf</code>ing my <code>~/.gnupg</code> directory for a fresh start. I
+also set the <code>GNUPGHOME</code> environment variable to a directory on the SD card
+which I use specifically to store key data. On this SD card are key files, SSH
+keys, and now GPG keys all under LUKS encryption (don't worry, I keep many
+copies of this SD card on other cards, USB sticks, and hard drives). Having a
+separate portable medium for my keys makes it so that I only have to worry about
+updating what's on the card instead of what's on all of the machines on which I
+am using GPG. It's also technically a lot easier to hide or destroy, but I don't
+see myself realistically needing to do that.</p>
+
+<h3>Generating the Master Key</h3>
+
+<p>Generating the master key is pretty straightforward.</p>
+
+<pre><code>$ gpg --full-gen-key --expert
+</code></pre>
+
+<p><code>--expert</code> is required because I wanted to use <a href="https://en.wikipedia.org/wiki/Elliptic-curve_cryptography">Elliptic Curve
+Cryptography</a>
+(<code>ed25519</code> keys in particular) instead of RSA since ECC keys are smaller for a
+similar level of security. From the article linked above: "a 256-bit elliptic
+curve public key should provide comparable security to a 3072-bit RSA public
+key". This will make typing in the key a lot easier and less error-prone should
+I have to restore it from paper backups. It's also fewer bits to send over the
+Internet when sharing my public keys.</p>
+
+<h3>Generating a Revocation Certificate</h3>
+
+<p>It's very important to have a revocation certificate since it's what one
+publishes if their key is ever compromised or otherwise needs to be revoked.
+It's essentially a way for one to tell the world "under no circumstances should
+you use or trust this key." Unlike with subkeys, revoking a master key is much
+more significant since, once that becomes compromised or lost, one has to start
+again from scratch.</p>
+
+<pre><code>$ gpg --gen-revoke --armor --output=revocation-certificate.asc <user-id>
+</code></pre>
+
+<p>Where <code><user-id></code> in this case is the email I specified when generating my key:
+<code>jbauer@paritybit.ca</code>.</p>
+
+<h3>Generating Subkeys</h3>
+
+<p>Typically, one shouldn't be using their master key for every-day use. That's
+because one's master key is used for signing others' keys, issuing new keys, and
+it's the ultimate representation of one's GPG identity. Instead, one should use
+subkeys as it's far easier to revoke them and issue new ones in the case that
+they become compromised.</p>
+
+<p>I generated one subkey specifically for signing and one subkey specifically for
+encryption:</p>
+
+<pre><code>$ gpg --edit-key --expert jbauer@paritybit.ca
+>addkey
+</code></pre>
+
+<p>I also set a one month expiry on both of those subkeys. While I think having an
+expiring master key is overkill for my uses and would be too much hassle, having
+subkeys expire is useful in the case that access to those subkeys is lost. This
+allows me to be less neurotic about backing up my subkeys compared to backing up
+my master key.</p>
+
+<p>I chose a length of one month because it will keep me coming back to GPG
+regularly. This way, I can both make sure that my master key backups have not
+become corrupted without my knowledge and that I keep my GPG skills honed. It
+also gets me in the habit of doing monthly maintenance on my keyring.</p>
+
+<h3>Going Backup Crazy</h3>
+
+<p>To make sure that my master key and revocation certificate stay as private as
+possible and to minimize the risk of me ever losing access to them, I went a
+little bit crazy with the number of backup copies I made.</p>
+
+<p>It's extremely important to have physical copies of both because digital media
+can fail over time in ways that are hard to detect until one needs to access the
+data. I printed my revocation certificate directly since it's just a short bit
+of ascii text and I printed out my master key using <code>paperkey</code>. Both of these
+pieces of paper went into my fire- and water-proof storage bag.</p>
+
+<pre><code>$ gpg --export-secret-key jbauer@paritybit.ca > privkey.gpg
+$ paperkey --secret-key privkey.gpg --output printed.txt
+$ lpr printed.txt
+$ rm privkey.gpg printed.txt
+</code></pre>
+
+<p>I also made several digital copies of my private key. First, I exported my
+master key using:</p>
+
+<pre><code>$ gpg --export-secret-keys --armor jbauer@paritybit.ca > master.asc
+</code></pre>
+
+<p>Then, using GPG's symmetric encryption capabilities, I encrypted both it and my
+revocation certificate using a completely new, randomly generated passphrase:</p>
+
+<pre><code>$ gpg -c master.asc
+$ gpg -c revocation-certificate.asc
+$ rm master.asc revocation-certificate.asc
+</code></pre>
+
+<p>I then put both of the new encrypted files: <code>master.asc.gpg</code> and
+<code>revocation-certificate.asc.gpg</code> onto two separate CDs—one went into my
+fireproof bag—and onto a floppy disk which also went into my fireproof bag. As
+soon as I have a free USB key, I'll be making a copy on that too.</p>
+
+<h3>Uploading My Keys to a Keyserver</h3>
+
+<p>Using a keyserver allows for both easier access to my public keys for others as
+well as convenient offsite storage for the public part of my master key which is
+required to restore the private part of my master key using <code>paperkey</code>. A while
+back, <a href="https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f">an attack on the SKS keyserver network was
+discovered</a>
+which caused many to become apprehensive about using keyservers. A solution
+proposed in the linked article was to use
+<a href="https://keys.openpgp.org">keys.openpgp.org</a> which is a new keyserver designed
+to mitigate the issues with the old keyservers. Following the <a href="https://keys.openpgp.org/about/usage">given
+instructions</a>, I uploaded my public keys
+so others should now be able to find me by searching for my email. Any time I
+need to use my master key (e.g. to sign another's key or renew my subkeys), I
+can re-sync my public keys with the keyserver so they always stay up to date in
+others' keyrings.</p>
+
+<h3>Configuring GPG and GPG-Agent</h3>
+
+<p>This is pretty simple and straightforward. Taking a few notes from the Arch wiki
+and setting options that I wanted to avoid having to type each time I ran <code>gpg</code>,
+I came up with the following configuration files:</p>
+
+<pre><code>gpg.conf
+--------
+keyserver hkps://keys.openpgp.org
+keyid-format long
+with-fingerprint
+with-subkey-fingerprint
+personal-digest-preferences SHA512
+cert-digest-algo SHA512
+default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
+</code></pre>
+
+<pre><code>gpg-agent.conf
+--------------
+# Cache for a day
+max-cache-ttl 86400
+default-cache-ttl 86400
+# Use curses-based pinentry program
+pinentry-program /usr/bin/pinentry-curses
+</code></pre>
+
+<h3>Deleting My Master Key</h3>
+
+<p>All of that backing up and making offline copies of my master key is so that I
+can do daily tasks with just my subkeys. To make this make sense, I have to
+delete my master key out of my keyring so it only exists offline until I need to
+use it. Since GnuPGv2.1, this is fairly straightforward:</p>
+
+<pre><code>$ gpg --list-keys --with-keygrip
+$ rm /media/jbauer/keys/gpg/private-keys-v1.d/<keygrip>.key
+</code></pre>
+
+<p>After decrypting it from one of my backups, I can then later restore this key
+(which I'll have to do at least once a month) by re-importing it with:</p>
+
+<pre><code>$ gpg --import master.asc
+</code></pre>
+
+<h3>Conclusion</h3>
+
+<p>Without a doubt, using GPG is quite complicated. There are a variety of
+decisions that one can make depending on their desired level of security or
+anonymity which can be overwhelming if one doesn't have much experience. I've
+spent probably 3 or 4 hours making sure that my processes are sound and making
+sure I'm doing everything right. To be honest, since I'm relatively new to using
+GPG seriously, I won't be 100% sure I'm doing things right until I can
+experience using it in the real world.</p>
+
+<p><em>This is my twenty-second post for the
+<a href="https://social.paritybit.ca/tags/100DaysToOffload">#100DaysToOffload</a>
+challenge. You can learn more about this challenge over at
+<a href="https://100daystooffload.com">https://100daystooffload.com</a>.</em></p>]]></description>
+</item>
+<item>
<title>Self Hosting Email</title>
<link>https://www.paritybit.ca/blog/self-hosting-email</link>
<guid>https://www.paritybit.ca/blog/self-hosting-email</guid>
diff --git a/public/sitemap.xml b/public/sitemap.xml
@@ -3,6 +3,7 @@
<url><loc>https://www.paritybit.ca</loc></url>
<url><loc>https://www.paritybit.ca/home</loc></url>
<url><loc>https://www.paritybit.ca/blog</loc></url>
+ <url><loc>https://www.paritybit.ca/blog/setting-up-gpg-keys-from-scratch</loc></url>
<url><loc>https://www.paritybit.ca/blog/self-hosting-email</loc></url>
<url><loc>https://www.paritybit.ca/blog/preparing-to-self-host-email</loc></url>
<url><loc>https://www.paritybit.ca/blog/diving-deeper-into-the-small-internet</loc></url>
