use spelling "subkey" consistently

closes #6

1 files changed, 15 insertions, 15 deletions

diff --git a/sq-guide.md b/sq-guide.md
index 3b41088..266cfd0 100644
--- a/sq-guide.md
+++ b/sq-guide.md
@@ -443,7 +443,7 @@ algorithms, allowing for a managed migration towards stronger
 security, and without losing access to older files and messages.
 
 
-## Why use sub-keys?
+## Why use subkeys?
 
 Even someone having only one cryptographic key may benefit from having
 other keys for specific purposes. For example, they might have a very
@@ -452,18 +452,18 @@ keys for encryption or digital signatures. Such auxiliary keys can be
 tied to the primary key using _certifications_, which we'll cover in
 more detail later. For now, a certification uses the primary key to
 declare that the auxiliary key can be used instead of the primary key
-for a specific purpose. The auxiliary key then becomes a _sub key_,
+for a specific purpose. The auxiliary key then becomes a _subkey_,
 and other users of OpenPGP will use it automatically, if they have
 your certificate. This setup has several benefits:
 
-* you can have separate sub keys for encryption, signing, or
+* you can have separate subkeys for encryption, signing, or
   authentication
 * you can use a smaller key when less security is OK in exchange for
   faster use
-* you can have a separate sub key for each device you have, or put
+* you can have a separate subkey for each device you have, or put
   them on a hardware security token
-* you can replace the sub keys easily: others trust your certificate,
-  and will happily use any sub key they can verify using your
+* you can replace the subkeys easily: others trust your certificate,
+  and will happily use any subkey they can verify using your
   certificate
 
 All of this is managed pretty much automatically using OpenPGP
@@ -472,13 +472,13 @@ software.
 
 ## Why would keys expire automatically?
 
-A key, whether primary or sub key, can be set to expire at a given
+A key, whether primary or subkey, can be set to expire at a given
 time. This is a precaution against you losing access to the primary
 key: if the key expires, others won't use it anymore. You can extend
 the expiration as often as you wish, although that requires getting
 your update certificate to everyone who needs to use it.
 
-You can also set sub keys to expire. This has the same benefits as
+You can also set subkeys to expire. This has the same benefits as
 expiring the primary key.
 
 Changing expiration times can be a chore. There's a security benefit
@@ -517,7 +517,7 @@ OpenPGP software) will know to not use that key anymore. We'll cover
 key revocation in more detail later.
 
 You can choose the cryptographic algorithm, and whether the key should
-have sub keys for signing or encrypting messages. See the `--help`
+have subkeys for signing or encrypting messages. See the `--help`
 output for the option names.
 
 
@@ -532,7 +532,7 @@ sq key extract-cert --output=cert.pgp key.pgp
 The `cert.pgp` file is the certificate (choose whatever name you want
 for it). You need to re-extract the certificate every time you make a
 change to the key that would shared with others: user ids, expiration
-times, sub keys.
+times, subkeys.
 
 Note that while one can extract a certificate from a key, the other
 direction is not possible.
@@ -551,7 +551,7 @@ A caveat: a certificate does contain all the user ids on your key, so
 if any of those is not public information you may want to remove them
 from your key before extracting the certificate. You may want to have
 an entirely separate key for that. User ids are tied to the primary
-key, sub keys inherit them from their primary.
+key, subkeys inherit them from their primary.
 
 # Using digital signatures
 
@@ -592,8 +592,8 @@ but for any kind of data, including files and cryptographic keys.
   they can't read it, if it's encrypted, they can at least make sure
   you don't get it.
 
-* When you add sub keys, they are signed by the primary key to prove
-  that you, the key holder, wants the sub key to be used.
+* When you add subkeys, they are signed by the primary key to prove
+  that you, the key holder, wants the subkey to be used.
 
 ## Making a signature
 
@@ -757,7 +757,7 @@ specifics that have been covered in the rest of the book.
 ## How to sign a file to share with others
 ## How to decrypt a message from someone else
 ## How to encrypt a message for someone else
-## How to generate a key, with sub keys, and a certificate
+## How to generate a key, with subkeys, and a certificate
 ## How to distribute certificate to others
 ## How to certify someone else's user id
 
@@ -826,7 +826,7 @@ The first word of the line tells you what the line contains:
 * `sec`---a secret key (i.e., key, in `--list-secret-keys` output)
 * `sec#`---a secret key is known to exist, but isn't actually in the keyring
 * `uid`---a userid attached to the key
-* `sub`---a sub key
+* `sub`---a subkey
 
 The `unknown` tells you how much you've told GnuPG you trust that user
 id. There's also information about type and length of a key, what it's