paritybit.ca

Unnamed repository; edit this file 'description' to name the repository.
Log | Files | Refs | README | LICENSE

commit 94db0a9581000617d0354f7b484ea433376c096a
parent 9329e48c350d39520d70939661877913ad2f39c2
Author: Jake Bauer <jbauer@paritybit.ca>
Date:   Sun, 17 May 2020 23:53:47 -0400

Publish new blog post

Diffstat:
Mpages/blog.md | 1+
Apages/blog/setting-up-gpg-keys-from-scratch.md | 211+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mpages/home.md | 4++--
Mpublic/feeds/sitewide-feed.xml | 211+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Mpublic/sitemap.xml | 1+
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 &lt;user-id&gt; +</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/&lt;keygrip&gt;.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 &lt;user-id&gt; +</code></pre> + +<p>Where <code>&lt;user-id&gt;</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/&lt;keygrip&gt;.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>