tKNOWN_BUGS.md - tomb - the crypto undertaker
(HTM) git clone git://parazyd.org/tomb.git
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
tKNOWN_BUGS.md (4271B)
---
1 # Usage of AES128 due to shorter keysize
2 ## 2.4
3
4 All tomb keys forged using Tomb version 2.3 or preceeding are 256 bits
5 large, which is insufficient to trigger usage of AES-256 encryption in
6 XTS mode, which is the default. Therefore all tombs locked using
7 smaller keys are silently encrypted using AES-128, according to the
8 cryptsetup manual:
9 > "By default a 256 bit key-size is used. Note however that XTS splits the supplied key in half, so to use AES-256 instead of AES-128 you have to set the XTS key-size to 512."
10
11 This problem has been noticed and corrected in Tomb version 2.4 where
12 now the 'forge' command will automatically generate 512 bits keys. To
13 switch to AES-256 encrypted tombs the only possibility is to create
14 new keys, new tombs and copy the contents across, since the LUKS
15 formatting occurs when the 'lock' command is issued using a new
16 key. Using 'setkey' to switch key does not suffice to switch to
17 AES-256.
18
19 This problem is minor and doesn't seem to heavily affect the security
20 of Tombs created before 2.4 as the cryptographic strenght of AES-128
21 and AES-256 is comparable; yet it is reasonable to think that larger
22 key sizes resist better to Quantum computing attacks.
23
24
25 # Vulnerability to password bruteforcing
26 ## Issue affecting keys used in steganography
27
28 An important part of Tomb's security model is to *make it hard for
29 attackers to enter in possession of both key and data storage*: once
30 that happens, bruteforcing the password can be relatively easy.
31
32 Protection from bruteforcing is provided by the KDF module that can
33 be optionally compiled in `extras/kdf-keys` and installed.
34
35 If a key is buried in an image and then the image is stolen, the KDF
36 protection does not works because *attackers can bruteforce easily
37 using steghide dictionary attacks*: once found the password is the
38 same for the steg crypto and the key crypto.
39
40 Users should keep in mind these issues when planning their encryption
41 scheme and, when relying on steganography, keep the image always
42 mixed in the same folder with many more images since that will be the
43 multiplier making it slightly harder to bruteforce their password.
44
45 In most cases consider that *password bruteforce is a feasible attack
46 vector on keys*. If there are doubts about a key being compromised is
47 a good practice to change it using the `setkey` command on a secure
48 machine, possibly while off-line or in single user mode.
49
50 # Ending newline in tomb keys
51 ## 2.2
52
53 When used to forge new keys, Tomb version 2.2 incorrectly added a new
54 line ('\n', 0x0A) character at the end of each key's secret sequence
55 before encoding it with GnuPG. This does not affect Tomb regression
56 and compatibility with other Tomb versions as this final newline is
57 ignored in any case, but third party software may have
58 problems. Those writing a software that supports opening Tomb files
59 should always ignore the final newline when present in the secret
60 material obtained after decoding the key with the password.
61
62 # Versioning and stdin key
63 ## 1.5
64
65 Due to distraction tomb version 1.5 displays its version as 1.4.
66 Also version 1.5 did not work when using -k - to pipe keys from
67 stdin, plus left the encrypted keys laying around in RAM (tmpfs).
68 This was a minor vulnerability fixed in 1.5.1.
69
70
71 # Key compatibility broken
72 ## 1.3 and 1.3.1
73
74 Due to an error in the creation and decoding of key files, release
75 versions 1.3 and 1.3.1 cannot open older tombs, plus the tombs created
76 with them will not be opened with older and newer versions of Tomb.
77
78 This bug was fixed in commit 551a7839f500a9ba4b26cd63774019d91615cb16
79
80 Those who have created tombs with older versions can simply upgrade
81 to release 1.4 (and any other following release) to fix this issue
82 and be able to operate their tombs normally.
83
84 Those who have used Tomb 1.3 or 1.3.1 to create new tombs should use
85 Tomb version 1.3.1 (available from https://files.dyne.org/tomb) to
86 open them and then migrate the contents into a new tomb created using
87 the latest stable Tomb version.
88
89 This bug was due to a typo in the code which appended a GnuPG status
90 string to the content of keys. All users of Tomb 1.3.* should pay
91 particular attention to this issue, however that release series was
92 out as latest for less than a month.