From 930b4148899f11feccea170ef888366481ec6555 Mon Sep 17 00:00:00 2001 From: Damien Ready Date: Fri, 1 Oct 2021 11:21:11 -0500 Subject: [PATCH] Correct some typos --- INSTALL.md | 2 +- KNOWN_BUGS.md | 6 +++--- README.md | 2 +- doc/KEY_SPECIFICATIONS.txt | 8 +++----- doc/LinuxHDEncSettings.txt | 8 ++++---- 5 files changed, 12 insertions(+), 14 deletions(-) diff --git a/INSTALL.md b/INSTALL.md index 1dd7b15..0855e5b 100644 --- a/INSTALL.md +++ b/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. diff --git a/KNOWN_BUGS.md b/KNOWN_BUGS.md index 6472606..4ea71db 100644 --- a/KNOWN_BUGS.md +++ b/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 diff --git a/README.md b/README.md index 4eb9c11..e03fdba 100644 --- a/README.md +++ b/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 ``` diff --git a/doc/KEY_SPECIFICATIONS.txt b/doc/KEY_SPECIFICATIONS.txt index 80443fd..78ea036 100644 --- a/doc/KEY_SPECIFICATIONS.txt +++ b/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 ====== diff --git a/doc/LinuxHDEncSettings.txt b/doc/LinuxHDEncSettings.txt index 205f3e4..c738edf 100644 --- a/doc/LinuxHDEncSettings.txt +++ b/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