Known Bugs

Vulnerability to password bruteforcing

Issue affecting keys used in steganography

An important part of Tomb's security model is to make it hard for attackers to enter in possession of both key and data storage: once that happens, brute-forcing the password can be relatively easy.

Protection from brute-forcing is provided by the KDF module that can be optionally compiled in extras/kdf-keys and installed.

If a key is buried in an image and then the image is stolen, the KDF protection does not works because attackers can brute-force easily using steghide dictionary attacks: once found the password is the same for the steg crypto and the key crypto.

Users should keep in mind these issues when planning their encryption scheme and, when relying on steganography, keep the image always mixed in the same folder with many more images since that will be the multiplier making it slightly harder to brute-force their password.

In most cases consider that password bruteforce is a feasible attack vector on keys. If there are doubts about a key being compromised is a good practice to change it using the setkey command on a secure machine, possibly while off-line or in single user mode.

Ending newline in tomb keys

Tomb 2.2

When used to forge new keys, Tomb version 2.2 incorrectly added a new line ('\n', 0x0A) character at the end of each key's secret sequence before encoding it with GnuPG. This does not affect Tomb regression and compatibility with other Tomb versions as this final newline is ignored in any case, but third party software may have problems. Those writing a software that supports opening Tomb files should always ignore the final newline when present in the secret material obtained after decoding the key with the password.

Versioning and stdin key

Tomb 1.5

Due to distraction tomb version 1.5 displays its version as 1.4. Also version 1.5 did not work when using -k - to pipe keys from stdin, plus left the encrypted keys laying around in RAM (tmpfs). This was a minor vulnerability fixed in 1.5.1.

Key compatibility broken

Tomb 1.3 and Tomb 1.3.1

Due to an error in the creation and decoding of key files, release versions 1.3 and 1.3.1 cannot open older tombs, plus the tombs created with them will not be opened with older and newer versions of Tomb.

This bug was fixed in commit 551a7839f500a9ba4b26cd63774019d91615cb16

Those who have created tombs with older versions can simply upgrade to release 1.4 (and any other following release) to fix this issue and be able to operate their tombs normally.

Those who have used Tomb 1.3 or 1.3.1 to create new tombs should use Tomb version 1.3.1 (available from https://files.dyne.org/tomb) to open them and then migrate the contents into a new tomb created using the latest stable Tomb version.

This bug was due to a typo in the code which appended a GnuPG status string to the content of keys. All users of Tomb 1.3.* should pay particular attention to this issue, however that release series was out as latest for less than a month.

Password Spaces Bug

Tomb 1.2

First of all, an important notice: the previous version of Tomb had a bug. A VERY GRAVE BUG. Passwords containing odd characters where badly interpreted: this means that if you password was I am 12!! perfectly 7^!@^#38123 secure, it could have been understood by tomb as I. yes, it was "split" at the first odd character. And yes, you thought to have a really great passphrase. Instead, you were using a single character one. Try it yourself, even with an old release of tomb. You might be able to open your tomb using just I as password.

Now, this bug has been fixed. This, however, won't fix the tomb that you created and used. You need to create a new one, move the content, then securely delete the old tomb and the old key.

Is it my case? There are several ways to check:

1. Askpass: use tomb askpass. Enter your password, and check if it printed what you typed, or a shorter one.

2. Try a shorter password: Suppose your password is a very good password. Try using just a as password. If it correctly opens your password, you are affected by the bug.

That's my case! what should I do now? If you still use tomb 1.0, you have to do it the hard way. Otherwise, use tomb passwd (see below)

1. The hard way: Well, actually not that hard.

   • Create a new tomb, and use a password with no spaces.
   • Move the content from the old to the new one.
   • WIPE the old tomb and, most importantly, the old key (actually, wiping the key should be enough). Please note that you shouldn't just delete the file; you have to securely delete it. There are lots of tools that can do it, although their effectiveness is debated, especially on journaling filesystems, like ext3/ext4. You can check wipe, srm. shred Note that, if you have copies of your old key, you should wipe them as well

2. Passwd: We are working on the introduction of a tomb subcommand to change password to your key. It has NOT yet been merged in mainline however. The usage should be:

   tomb passwd $keyfile

   And be similar to the traditional passwd unix command: ask the old password, then confirm the new one two times.