Correct some typos

INSTALL.md

@@ -51,7 +51,7 @@ The key can also be hidden in an image, to be used as key later
     tomb bury -k secrets.tomb.key nosferatu.jpg (hide the key in a jpeg image)
     tomb open -k nosferatu.jpg secrets.tomb (use the jpeg image to open the tomb)
 
-Or backupped to a QRCode that can be printed on paper and hidden in
+Or backed up to a QRCode that can be printed on paper and hidden in
 books. QRCodes can be scanned with any mobile application, resulting
 into a block of text that can be used with `-k` just as a normal key.
 

KNOWN_BUGS.md

@@ -22,16 +22,16 @@ cryptsetup v2.1 a new default has been introduced (luks2) and the
 Using Tomb version 2.6 (and future releases) the problem opening tombs
 using recent GNU/Linux distributions is fixed.
 
-# Whitespaces in KDF passwords
+# Whitespace in KDF passwords
 ## Issue affecting passwords used with PBKDF2 keys (<2.6)
 
  Up until and including Tomb's version 2.5 the PBKDF2 wrapper for keys
- in Tomb has a bug affecting passwords that contain whitespaces. Since
+ in Tomb has a bug affecting passwords that contain whitespace. Since
  the passwords are trimmed at the first whitespace, this makes them
  weaker, while fortunately the KDF transformation still applies.
 
  This issue is fixed in Tomb version 2.6: all users adopting KDF keys
- that have passwords containing whitespaces should change them,
+ that have passwords containing whitespace should change them,
  knowing that their "old password" is trimmed until the whitespace.
 
  Users adopting GPG keys or plain (without KDF wrapper) can ignore

README.md

@@ -112,7 +112,7 @@ or if you are in a hurry
 
    -h     print this help
    -v     print version, license and list of available ciphers
-   -q     run quietly without printing informations
+   -q     run quietly without printing information
    -D     print debugging information at runtime
 ```
 

doc/KEY_SPECIFICATIONS.txt

@@ -1,13 +1,11 @@
 Overview
 =========
 
-
-What's a key?
-It basicly is a gpg simmetrically encrypted, ascii-armored file.
-It's encryption key is a function (see below, on KDF section) of your tomb
+What is a key?
+It is a gpg symmetrically encrypted, ascii-armored file.
+The encryption key is a function (see below, on KDF section) of your tomb
 passphrase.
 
-
 Layout
 ======
 

doc/LinuxHDEncSettings.txt

@@ -31,11 +31,11 @@ Linux hard disk encryption settings
    and LRW for standardisation. EME along with it's cousin CMC seems to
    provide the best security level, but imposes additional encryption
    steps. Plumb-IV is discussed only for reference, because it has the
-   same performance penalty as CMC, but in constrast suffers from
+   same performance penalty as CMC, but in contrast suffers from
    weaknesses of CBC encryption.
 
    As convention, this document will use the term "blocks", when it
-   referes to a single block of plain or cipher text (usually 16 byte),
+   refers to a single block of plain or cipher text (usually 16 byte),
    and will use the term "sectors", when it refers to a 512-byte wide hard
    disk block.
 
@@ -171,8 +171,8 @@ Content leaks
    cipher blocks. But how does this number grow in n? Obviously
    exponentially. Plotting a few a decimal powers shows that the chance
    for finding at least on identical cipher pair flips to 1 around n =
-   10^20 (n = 10^40 for a 256-bit cipher). This inflexion point is reached
-   for a 146 million TB storage (or a hundered thousand trillion trillions
+   10^20 (n = 10^40 for a 256-bit cipher). This inflection point is reached
+   for a 146 million TB storage (or a hundred thousand trillion trillions
    TB storage for a 256-bit cipher).
 
    ^1The blocks with available preceding cipher blocks is 62/1KB for all