Spellchecking

Author: KellerFuchs

Devices.md

@@ -72,7 +72,7 @@ See: [https://www.nitrokey.com/]
 
 The VivoKey is an NFC-only device designed to cover the bulk of use cases of the YubiKey Neo while also having space for general user-supplied applications such as transit pass emulation via the Fidesmo platform. It is Paralyne-C coated and on a flexible PCB intended for implantation and is currently in human trials.
 
-For people who are not as into scapels, it would of course be possible to insert such a device into a watch band or bracelet.
+For people who are not as into scalpels, it would of course be possible to insert such a device into a watch band or bracelet.
 
 ![VivoKey](assets/img/vivokey.png)
 

Use_Cases/Building_Access.md

@@ -1,7 +1,7 @@
 # Building Access
 
-Most building access systems tend to use 125Khz unencrypted HID cards such as a Proxcard II.
+Most building access systems tend to use 125KHz unencrypted HID cards such as a Proxcard II.
 
 These can be cloned trivially to any writable T5577 tag via a professional RFID analysis tool like a Proxmark 3 or even a cheap generic cloner. 
 
-Other buildings often support 13.56Mhz MiFare NFC cards with no encryption. A smartphone can easily clone these to most NFC tags, or a NFC enabled Security Token like a Yubikey Neo.
+Other buildings often support 13.56MHz MiFare NFC cards with no encryption. A smartphone can easily clone these to most NFC tags, or a NFC enabled Security Token like a YubiKey Neo.

Use_Cases/Commit_Signing.md

@@ -39,7 +39,7 @@ every line of code between releases on the individual cutting a release. In a
 large codebase this is an unreasonable expectation.
 
 Having signing and review at every PR between releases distributes
-responsibility more fairly. When you sign a commit or sign a mege commit after
+responsibility more fairly. When you sign a commit or sign a merge commit after
 a PR you are signing only that one chunk of code or subset of changes and
 creating a smaller set of checks and balances through the release cycle.
 

Use_Cases/GPG/Advanced_Setup.md

@@ -8,7 +8,7 @@ You should ideally perform these steps from an "airgapped" system, such as from
 a Linux Live-CD not connected to the internet.
 
 Unlike the "Simple Setup" steps, this will result in your Master key being
-offline and only Subkeys will exist on the Security Token. This will mean your
+offline and only subkeys will exist on the Security Token. This will mean your
 Security Token will lack the Certify permission, meaning it will not be able to
 sign other GPG keychains.
 
@@ -19,7 +19,7 @@ of other people.
 ## Prepare Offline Storage Directory
 
 This directory needs to be kept on an offline device (USB drive, etc) in a
-stable location (Fireproof box, safe, under your matress, etc)
+stable location (Fireproof box, safe, under your mattress, etc)
 
 This will contain:
  * Backup plaintext secret keys, useful for emergencies
@@ -122,7 +122,7 @@ revocation, and further manipulation of your key (and its subkeys).
 
 When the Security Token is set up you likely won't need this password for daily
 operation but it should be maintained in your brain. You could also store only
-part of the password in memory, and a long complex part in a usb drive in a 
+part of the password in memory, and a long complex part in a USB drive in a 
 secure location.
 
 ```
@@ -694,7 +694,7 @@ gpg> save
 The following is critical to ensure no private keys are left on disk, and that
 you are in fact are only relying on the private keys in your Security Token.
 
-If you heeded the advice in this document of working from a LiveCD this still
+If you heeded the advice in this document of working from a Live CD this still
 serves as a good test.
 
 We opt for a "clean room" approach here to ensure you could use your key as

Use_Cases/GPG/Simple_Setup.md

@@ -2,9 +2,9 @@
 
 These steps are the simplest way to initialize a Security Token for GPG however If you lose the key or forget the PIN, you will not be able to recover it!
 
-This is only recommended where you universally have administrators or peers capable of revoking and rotating all of your credentials if nessesary.
+This is only recommended where you universally have administrators or peers capable of revoking and rotating all of your credentials if necessary.
 
-If you are wanting to setup a GPG on a Security Token for mixed or personal use, or are an administator it is recommended to use the Advanced Setup which will allow you an opprotunity to make a secure offline backup of key data.
+If you are wanting to setup a GPG on a Security Token for mixed or personal use, or are an administrator it is recommended to use the Advanced Setup which will allow you an opportunity to make a secure offline backup of key data.
 
 ## Configure PIN codes
 

Use_Cases/SSH.md

@@ -2,9 +2,9 @@
 
 ## Configure SSH to use your Security Token
 
-This assumes you already have a Security Token configured with a GPG Authentication Subkey.
+This assumes you already have a Security Token configured with a GPG Authentication subkey.
 
-The end result will be that you distribute the SSH Public Key from your Security Token to all VCS systems and servers you normally connect to via SSH. From there you will need to have your key insert it, and tap it once for every connection. You will also be required to tap the key for all SSH Agent forwarding hops removing many of the security issues with traditiional ssh agent forwarding on shared systems.
+The end result will be that you distribute the SSH Public Key from your Security Token to all VCS systems and servers you normally connect to via SSH. From there you will need to have your key insert it, and tap it once for every connection. You will also be required to tap the key for all SSH Agent forwarding hops removing many of the security issues with traditional ssh agent forwarding on shared systems.
 
 ### Configure gpg-agent to also behave as an ssh-agent: