Llewellyn/Tomb
1
0
Fork 0
mirror of https://github.com/Llewellynvdm/Tomb.git synced 2024-11-12 07:46:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

manpage, documentation and fixes for the new release

Browse Source 
includes also timeout to ask_usbkey, correct naming of tomb
reference documentation for encryption settings, webpage updates and artworks
This commit is contained in:
Jaromil 2011-01-28 12:26:35 +01:00
parent 85fe9295bd
commit eac4818f30
13 changed files with 1911 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
.gitignore vendored
View File

@ -1,16 +1,19 @@
\#*
.\#*
*~
*.o
tomb-askpass
tomb-status
.deps
!autogen.sh
aclocal.m4
autom4te.cache
config.guess
config.guess*
config.h
config.log
config.php
config.status
config.sub
config.sub*
configure
config.h.in
depcomp
@ -22,3 +25,6 @@ Makefile.in
missing
stamp-h1
tags
doc/web/public
doc/web/dyne

6
AUTHORS
View File

@ -1,4 +1,8 @@
Tomb is designed and written by Denis Roio <jaromil@dyne.org>
Tomb's artwork is contributed by Jordi aka MonMort
Tomb's artwork is contributed by Jordi aka Món Mort
Testing and fixes are contributed by Dreamer and Hellekin O. Wolf.

5
ChangeLog
View File

@ -1,3 +1,8 @@
January 2011
Tomb is now a desktop application following freedesktop standards:
it provides a status tray and integrates with file managers. The
main program has been thoroughly tested and many bugs were fixed.
August 2010

133
README.muse Normal file
View File

@ -0,0 +1,133 @@
#title Tomb - The Crypto Undertaker
#author Jaromil
<contents>
* Tomb - RIP
<example>
..... ..
.H8888888h. ~-. . uW8"
888888888888x `> u. .. . : `t888
X~ `?888888hx~ ...ue888b .888: x888 x888. 8888 .
' x8.^"*88*" 888R Y888r ~`8888~'888X`?888f` 9888.z88N
`-:- X8888x 888R I888> X888 888X '888> 9888 888E
488888> 888R I888> X888 888X '888> 9888 888E
.. `"88* 888R I888> X888 888X '888> 9888 888E
x88888nX" . u8888cJ888 X888 888X '888> 9888 888E
!"*8888888n.. : "*888*P" "*88%""*88" '888!` .8888 888"
' "*88888888* 'Y" `~ " `"` `%888*%"
^"***"` "`
a simple commandline tool to manage encrypted storage v.0.9
http://tomb.dyne.org by Jaromil @ dyne.org
</example>
** Introduction
Tomb aims to be an 100% free and open source system for easy
encryption and backup of personal files, written in code that is easy
to review and links commonly shared components.
At present time Tomb is easy to install and use, it mainly consists of
a Shell script and some auxiliary C code for desktop integration,
making use of GNU tools and the cryptographic API of the Linux kernel.
*** Who needs Tomb
Our target community are desktop users with no time to click around,
sometimes using old or borrowed computers, operating in places
endangered by conflict where a leak of personal data can be a threat.
If you don't own a laptop then it's possible to go around with a USB
stick and borrow computers, still leaving no trace and keeping your
data safe during transports. Tomb aims to facilitate all this and to
be interoperable across popular GNU/Linux operating systems.
*** Aren't there enough encryption tools already?
We've felt the urgency of publishing Tomb for other operating systems
than dyne:bolic since the current situation with [[http://en.wikipedia.org/wiki/TrueCrypt][TrueCrypt]] is far from
optimal. TrueCrypt makes use of statically linked libraries, its code
is not hosted on CVS and is [[http://lists.freedesktop.org/archives/distributions/2008-October/000276.html][not considered free]] by GNU/Linux
distributions because of liability reasons, see [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364034][Debian]], [[https://bugs.edge.launchpad.net/ubuntu/+bug/109701][Ubuntu]][4],
Suse[5], Gentoo[6] and Fedora[7].
Seen from this perspective, Tomb is intended as a rewrite of most
functionalities offered by TrueCrypt in a new application, confident
it won't take much relying on previous experience and aiming at:
- short and readable code, linking shared libs and common components
- easy graphical interface, simple for ad-hoc (DIY-deniable)
- transparent and distributed development hosted using GIT
- GNU General Public License v3
[1] http://en.wikipedia.org/wiki/TrueCrypt
[2] http://lists.freedesktop.org/archives/distributions/2008-October/000276.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364034
[4] https://bugs.edge.launchpad.net/ubuntu/+bug/109701
[5] http://lists.opensuse.org/opensuse-buildservice/2008-10/msg00055.html
[6] http://bugs.gentoo.org/show\_bug.cgi?id=241650
[7] https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
*** How does it works
Tomb generates 'key files' and protects them with a password choosen
by the user; the key files are then used to encrypt loop-back mounted
partitions, like single files containing a filesystem inside: this way
keys can be separated from data for safer transports when
required.
** Downloads
For licensing information see the [[http://www.gnu.org/copyleft/gpl.html][GNU General Public License]]
Below a list of formats you can download this application: ready to be
run with some of the interfaces developed, as a library you can use to
build your own application and as source code you can study.
*** Code repository
Latest stable release is 0.9 (25 January 2011) more about it in the
[[ftp://ftp.dyne.org/tomb/NEWS][NEWS]] and [[ftp://ftp.dyne.org/tomb/ChangeLog][ChangeLog]]
Source releases are checked and signed by [[http://jaromil.dyne.org][Jaromil]] using [[http://www.gnupg.org][GnuPG]].
On [[ftp://ftp.dyne.org/tomb][ftp.dyne.org/tomb]] you find all present and past Tomb releases,
source code for extra plugins and more binaries that we occasionally
build for various architectures.
The bleeding edge version is developed on our [[http://code.dyne.org][code repository]] using
**GIT**, you can clone the repository free and anonymously
<example>
git clone git://code.dyne.org/tomb.git
</example>
** Development
*** Stage of development
Tomb is an evolution of the 'mknest' tool developed for the dyne:bolic
GNU/Linux distribution, which is used by its 'nesting' mechanism to
encrypt the Home directory of users.
As such, it uses well tested and reviewed routines and its shell code
is pretty readable. The name transition from 'mknest' to 'tomb' is
marked by the adaptation of mknest to work on the Debian operating
system, used by its author in the past 3 years.
*** How can you help
Code is pretty short and readable: start looking around it and the
materials found in doc/ which are good pointers at security measures
to be further implemented.
Have a look in the TODO file to see what our plans are.
At the moment we can use some good help in porting this tool on
M$/Windows and Apple/OSX, still keeping the minimal approach we all
love.

404
doc/LinuxHDEncSettings.txt Normal file
View File

@ -0,0 +1,404 @@
Linux hard disk encryption settings
This page intends to educate the reader about the existing weaknesses
of the public-IV on-disk format commonly used with cryptoloop and
dm-crypt (used in IV-plain mode). This page aims to facilitate risk
calculation when utilising Linux hard disk encryption. The attacks
presented on this page may pose a thread to you, but at the same time
may be totally irrelevant for others. At the end of this document, the
reader should be able to make a good choice according to his security
needs.
A good quote with respect to this topic is ''All security involves
trade-offs'' from Beyond Fear (Bruce Schneier). You should keep in mind
that perfect security is unachievable and by all means shouldn't be
your goal. For instance, when using pass phrase based cryptography, you
have to trust in that the underlying system is secure, the computer
system has not been tampered with, and nobody is watching you. The most
obvious weakness is the last one, but even if you make sure nobody nor
any camera is around, how about the keyboard you're typing on? Has it
been manipulated while you have been getting your lunch?
So security comes for a price, and the price when designing
cryptography security algorithms is performance. You will be introduced
to the fastest of all setups available, the "public-IV", which
sacrifices security properties for speed. After that we will talk about
ESSIV, the newest of IV modes implemented. It comes for a small price,
but it can deal with watermarking for a relatively small price. Then
you'll be introduced to the draft specifications of the Security in
Storage Working Group ([18]SISWG). Currently SISWG is considering EME
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
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),
and will use the term "sectors", when it refers to a 512-byte wide hard
disk block.
CBC Mode: The basic level
Most hard disk encryption systems utilise CBC to encrypt bulk data.
Good descriptions on CBC and other common cipher modes are available at
* [19]Wikipedia
* [20]Connected: An Internet Encyclopedia
* [21]NIST: Recommendation for Block Cipher Modes of Operation (CBC
is at PDF Page 17)
Please make sure you're familiar with CBC before proceeding.
Since CBC encryption is a recursive algorithm, the encryption of the
n-th block requires the encryption of all preceding blocks, 0 till n-1.
Thus, if we would run the whole hard disk encryption in CBC mode, one
would have to re-encrypt the whole hard disk, if the first computation
step changed, this is, when the first plain text block changed. Of
course, this is an undesired property, therefore the CBC chaining is
cut every sector and restarted with a new initialisation vector (IV),
so we can encrypt sectors individually. The choice of the sector as
smallest unit matches with the smallest unit of hard disks, where a
sector is also atomic in terms of access.
For reference, I will give a formal definition of CBC encryption and
decryption. Note, that decryption is not recursive, in contrast to
encryption, since it's a function only of C[n-1] and C[n].
Encryption:
C[-1] = IV
C[n] = E(P[n] ⊕ C[n-1])
Decryption:
C[-1] = IV
P[n] = C[n-1] ⊕ D(C[n])
The next sections will deal with how this IV is chosen.
The IV Modes
The "public-IV"
The IV for sector n is simply the 32-bit version of the number n
encoded in little-endian padded with zeros to the block-size of the
cipher used, if necessary. This is the most simple IV mode, but at the
same the most vulnerable.
ESSIV
E(Sector|Salt) IV, short ESSIV, derives the IV from key material via
encryption of the sector number with a hashed version of the key
material, the salt. ESSIV does not specify a particular hash algorithm,
but the digest size of the hash must be an accepted key size for the
block cipher in use. As the IV depends on a none public piece of
information, the key, the sequence of IV is not known, and the attacks
based on this can't be launched.
plumb IV
The IV is computed by hashing (or MAC-ing) the plain text from the
second block till the last. Additionally, the sector number and the key
are used as input as well. If a byte changes in the plain text of the
blocks 2 till n, the first block is influenced by the change of the IV.
As the first encryption effects all subsequent encryption steps due to
the nature of CBC, the whole sector is changed.
Decryption is possible because CBC is not recursive for decryption. The
prerequisites for a successful CBC decryption are two subsequent cipher
blocks. The former one is decrypted and the first one is XOR-ed into
the decryption result yielding the original plain text. Therefore
independent of the IV scheme, decryption is possible from the 2nd to
the last block. After the recovery of these plain text blocks, the IV
can be computed, and finally the first block can be decrypted as well.
The only weakness of this scheme is it's performance. It has to process
data twice: first for obtaining the IV, and then to produce the CBC
encryption with this IV. With the same performance penalty CMC is able
to achieve better security properties (CMC is discussed later), thus
plumb-IV will remain unimplemented.
The attack arsenal
Content leaks
This attack can be mounted against any system operating in CBC Mode. It
rests on the property, that in CBC decryption, the preceding cipher
block's influence is simple, that is, it's XORed into the plain text.
The preceding cipher block, C[n-1], is readily available on disk (for n
> 0) or may be deduced from the IV (for n = 0). If an attacker finds
two blocks with identical cipher text, he knows that both cipher texts
have been formed according to:
C[m] = E(P[m] ⊕ C[m-1] )
C[n] = E(P[n] ⊕ C[n-1] )
Since he found that C[m] = C[n], it holds
P[m] ⊕ C[m-1] = P[n] ⊕ C[n-1]
which can be rewritten as
C[m-1] ⊕ C[n-1] = P[n] ⊕ P[m]
The left hand side is known to the attacker by reading the preceding
cipher text from disk. If one of the blocks is the first block of a
sector, the IV must be examined instead (when it's available as it is
in public-IV). The attacker is now able to deduce the difference
between the plain texts by examining the difference of C[m-1] and
C[n-1]. If one of the plain text blocks happens to be zero, the
difference yields the original content of the other related plain text
block.
Another information is available to the attacker. Any succeeding
identical pair of cipher text, that follows the initial identical
cipher pair, is equal. No information about the content of those pairs
can be extracted, since the information is extracted from the
respective preceding cipher blocks, but those are all required to be
equal.
Let's have a look at the chance of succeeding with this attack.
Assuming the output of a cipher forms an uniform distribution, the
chance, p, of finding an identical block is 2^-blocksize. For instance,
p = 1/2^128 for a 128-bit cipher. Because the number of possible pairs
develops as an arithmetic series in n, the number of sectors, the
chance of not finding two identical blocks is given by
(1-p)^n(n-1)/2
As p is very small, but in contrast the power is very big, we apply the
logarithm to get meaningful answers, that is
n(n-1)/2 ln (1-p)
An example: The number of cipher blocks available on 200GB disk with
known C[n-1] is 200GB × 1024^2 KB/GB × 64/1KB ^1. Or in other words, a
128-bit block is 16 bytes, so the number of 16-byte blocks in a 200GB
hard disk is 13.4 billion. Therefore, n = 1.342e10. For a 128-bit
cipher, p = 2^-128. Hence,
ln(1-p) = -2.939e-39
n(n-1)/2 = 9.007e19
n(n-1)/2 ln (1-p) = -2.647e-19
1-e^-2.776e-13 = 2.647e-19
The last term is the chance of finding at least one pair of identical
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
TB storage for a 256-bit cipher).
^1The blocks with available preceding cipher blocks is 62/1KB for all
non-public IV schemes, i.e. ESSIV/plumb IV
Data existence leak: The Watermark
No IV format discussed on this page allows the user to deny the
existence of encrypted data. Neither cryptoloop nor dm-crypt is an
implementation of a deniable cryptography system. But the problem is
more serious with public-IV.
With public IV and the predicable difference it introduces in the first
blocks of a sequence of plain text, data can be watermarked, which
means, the watermarked data is detectable even when the key has not
been recovered. As shown in the paragraph above, the existence of two
blocks with identical cipher text is very unlikely and coincidence can
be excluded, which is relevant when somebody tries to demonstrate
before the law that certain data is in an encrypted partition.
As the IV progresses with a foreseeable pattern and is guaranteed to
change the least significant bit ever step, we can build identical pair
of cipher text by writing three consecutive sectors each with a flipped
LSB relative to the previous. (The reason it's three instead of two is,
that the second least significant bit might change as well.) This
"public-IV"-driven CBC encryption will output exactly the same cipher
text for two consecutive sectors. An attacker can search the disk for
identical consecutive blocks to find the watermark. This can be done in
a single pass, and is much more feasible than finding to identical
blocks, that are scattered on the disk, as in the previous attack. A
few bits of information can be encoded into the watermarks, which might
serve as tag to prove the existence copyright infringing material.
A complete description of watermarking can be found in [22]Encrypted
Watermarks and Linux Laptop Security. The attack can be defeated by
using ESSIV.
Data modification leak
CBC encryption is recursive, so the n-th block depends on all previous
blocks. But the other way round would also be nice. Why? The weakness
becomes visible, if storage on a remote computer is used, or more
likely, the hard disk exhibits good forensic properties. The point is,
the attacker has to have access to preceding (in time) cipher text of a
sector, either by recording it from the network, or by using forensic
methods.
An attacker can now guess data modification patterns by examining the
historic data. If a sector is overwritten with a partial changed plain
text, there is an amount of bytes at the beginning, which are
unchanged. This point of change^2 is directly reflected in the cipher
text. So an attacker can deduce the point of the change in plain text
by finding the point where the cipher text starts to differ.
This weakness is present in public-IV and ESSIV.
^2aligned to the cipher block size boundaries
Malleable plain text
The decryption structure of CBC is the source of this weakness.
Malleability (with respect to cryptography) is defined as a
modification of the cipher text that will resulting in a predictable
change in plain text. To put it formally, there is a function f(C),
that, if applied to the cipher text, C' = f(C), will result in a known
function f', which will predict the resulting plain text, P' = D(C'),
correctly assuming P is known, that is P' = f'(P).
As we can see in it's definition, CBC decryption depends on C[n-1]. An
attacker can flip arbitrary bits in the plain text by flipping bit in
C[n-1]. More formally^3, if
P = P[1] || P[2] || ... || P[i] || ... || P[n]
C = E[CBC](P)
C = C[1] || C[2] || ... || C[i-1] || ... || C[n]
the function
f(C[1] || ... || C[n]) = C[1] || ... || C[i-1] XOR M || ... || C[n]
follows the function f', which predicts the resulting plain text
correctly as,
f'(P[1] || ... || P[n]) = P[1] || ... || P[i] XOR M || ... || P[n]
The first block of the CBC cipher text stream is not malleable, because
it depends on the IV, which is not modifiable for an attacker.
^3The IV parameter for E[CBC] has been intentionally omitted.
Movable
On the expense of one block decrypting to garbage, an attacker can move
around plain text as he likes. CBC decryption depends on two variables,
C[n-1] and C[n]. Both can be modified at free will. To make meaningful
modifications, an attacker has to replace the pair C[n-1] and C[n] with
other cipher text pair from disk. The first block C[n-1] will decrypt
to garbage, but the second block C[n] will yield a copy of the plain
text of the copied cipher block. This attack is also known as
copy&paste attack. This attack is mountable against any CBC setup. The
only limitation is, the first block, C[0], can't be replaced with
something meaningful, as C[-1] can't be modified, because it's the IV.
CMC and EME: Tweakable wide block cipher modes
CMC is a new chaining mode. It stands for ''CBC-Mask-CBC''. It works by
processing the data in three steps, first CBC, then masking the cipher
text, and then another CBC step, but this time backwards. The last step
introduces a dependency from the last block to the first block. The
authors of the CMC paper provide a prove for the security of this mode,
making a secure 128-bit cipher a secure 4096-bit cipher (sector size).
As in normal CBC, this scheme also takes an IV, but the authors call it
tweak.
EME is CMC's cousin. EME has also been authored by Haveli and Rogaway
as well been authored for the same purpose. The difference to CMC is,
that EME is parallelizable, that is, all operations of the underlying
cipher can be evaluated in parallel. To introduce an interdependency
among the resulting cipher blocks, the encryption happens in two
stages. Between these stages a mask is computed from all intermediate
blocks and applied to each intermediate block. This step causes an
interdependency among the cipher blocks. After applying the mask,
another encryption step diffuses the mask.
The interdependency among the resulting blocks allow CMC and EME to be
nonmovable, nonmalleable, to prevent content leaks and in-sector data
modification patterns. The tweaks are encrypted by both cipher modes,
thus both are nonwatermarkable.
For simplicity, the EME description above omitted the pre- and post-
whitening steps as well as the multiplications in GF(2^128). An
in-depth specification can be found at the [23]Cryptology ePrint
Archive. An applicable draft specification for EME-32-AES can be found
at [24]SISWG. I have written an EME-32-AES test implementation for
Linux 2.6. It's available [25]here. The CMC paper is available from the
[26]Cryptology ePrint Archive as well.
LRW: A tweakable narrow block cipher mode
EME as well as CMC are comparatively secure cipher modes, but heavy in
terms of performance. LRW tries to cope with most of security
requirements, and at the same time provide a good performance. LRW is a
narrow block cipher mode, that is, it operates only on one block,
instead of a whole sector. To make a cipher block tied to a location on
disk (to make it unmovable), a logical index is included in the
computation. For LRW you have to provide two keys, one for the cipher
and one for the cipher mode. The second key is multiplied with a
logical index under GF(2^128) and used as pre- and post- whitening for
encryption. With those whitening steps the block is effectively tied to
a logical index. The logical index is usually the absolute position on
disk measured with the block size of the cipher algorithm. The
different choice of the measuring unit is the only different between
the logical index and the public-IV.
The LRW draft is available from the [27]SISWG mailing list archive.
Summarising
The following table shows a comparison between the security properties
of different encryption setups and their computational costs. The
number of cipher calls, XOR operations and additional operations are
stated in terms of encryption blocks, n.
IV mode cipher mode content leaks watermarkable malleable movable
modification detection^5 cipher calls XOR ops additional op.
public-IV CBC Yes Yes Yes Yes Yes n n None
ESSIV CBC Yes No Yes Yes Yes n+1 n None
Plumb-IV1^4 CBC Yes No Yes Yes No 2n-1 2n None
public-IV CMC No No No No No 2n+1 2n+1 1 LW GF ⊗
public-IV EME No No No No No 2n+1 5n 3n-1 LW GF ⊗
public-IV LRW No No No No Yes n 2n n HW GF ⊗
Legend:
* LW GF ⊗: light-weight Galois field multiplication, that is, a
multiplication with a constant x^2^i, which can be computed in
θ(1).
* HW GF ⊗: heavy-weight Galois field multiplication, that is, a
multiplication with an arbitrary constant, which can be computed in
θ(bits).
^4plumb-IV1 uses CBC-MAC instead of hashing, so we can make a good
comparison with other ciphers in terms of cipher/XOR calls.
^5detectable partial in-sector modification
__________________________________________________________________
Clemens Fruhwirth, , also author of LUKS and ESSIV, porter of
cryptoloop, aes-i586 for 2.6., twofish-i586, and implementor of
EME-32-AES. This text is an excerpt of my diploma thesis.
This page has been reviewed by
Dr. Ernst Molitor
Arno Wagner
James Hughes , "Security in Storage Working Group" chair
Additional thanks to Pascal Brisset, for pointing out an error in the
Bernoulli estimation in an earlier version of this document, further
Adam J. Richter for pointing out an error in the KB/GB ratio.
Content and design, Copyright © 2004-2008 Clemens Fruhwirth, unless
stated otherwise
Original design by [28]haran | Additional art by [29]LinuxArt | | Blog
by [30]NanoBlogger
References
1. http://clemens.endorphin.org/
2. http://clemens.endorphin.org/credits
3. http://clemens.endorphin.org/aboutme
4. http://clemens.endorphin.org/cryptography
5. http://blog.clemens.endorphin.org/
6. http://clemens.endorphin.org/patches
7. http://clemens.endorphin.org/archive
8. http://clemens.endorphin.org/Cryptoloop_Migration_Guide
9. http://clemens.endorphin.org/LUKS
10. http://clemens.endorphin.org/AFsplitter
11. http://clemens.endorphin.org/lo-tracker
12. http://blog.clemens.endorphin.org/2008/12/luks-on-disk-format-revision-111.html
13. http://blog.clemens.endorphin.org/2008/11/xmonad-gridselect.html
14. http://blog.clemens.endorphin.org/2008/11/workaround-for-bittorrent-traffic.html
15. http://blog.clemens.endorphin.org/2008/09/i-love-lolcat-meme.html
16. http://blog.clemens.endorphin.org/2008/09/counter-steganography-research.html
17. http://clemens.endorphin.org/cryptography
18. http://www.siswg.org/
19. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
20. http://www.freesoft.org/CIE/Topics/143.htm
21. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
22. http://www.tcs.hut.fi/~mjos/doc/wisa2004.pdf
23. http://eprint.iacr.org/2003/147/
24. http://grouper.ieee.org/groups/1619/email/pdf00011.pdf
25. http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/544
26. http://eprint.iacr.org/2003/148/
27. http://grouper.ieee.org/groups/1619/email/msg00160.html
28. http://www.oswd.org/user/profile/id/3013
29. http://www.linuxart.com/
30. http://nanoblogger.sourceforge.net/

2
doc/tomb.1
View File

@ -20,7 +20,7 @@ complete with programs to facilitate its operation by desktop users.
Tomb generates encrypted storage files to be opened and closed using
their associated keyfiles, which are also protected with a password
choosen by the user.
chosen by the user.
A tomb is like a locked folder that can be safely transported and
hidden in a filesystem; its keys can be kept separate, for instance

BIN
doc/web/views/images/monmort.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 446 B

BIN
doc/web/views/images/tomb_n_bats.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 74 KiB

56
doc/web/views/index.muse
View File

@ -25,18 +25,24 @@
^"***"` "`
a simple commandline tool to manage encrypted storage v.0.9
by Jaromil @ dyne.org
(from the hashes of dyne:bolic nesting)
</example>
** Introduction
Tomb aims to be an 100% free and open source system for easy
encryption and backup of personal files, written in code that is easy
to review and links commonly shared components.
At present time Tomb is easy to install and use, it mainly consists of
a Shell script and some auxiliary C code for desktop integration,
making use of GNU tools and the cryptographic API of the Linux kernel.
Tomb generates encrypted storage files to be opened and closed using
their associated keyfiles, which are also protected with a password
chosen by the user.
A tomb is like a locked folder that can be safely transported and
hidden in a filesystem; its keys can be kept separate, for instance
keeping the tomb file on your computer harddisk and the key files on a
USB stick.
** Documentation
*** Who needs Tomb
@ -80,15 +86,10 @@ To open a tomb is sufficient to click on it, or use the command **tomb-open**
When a tomb is open your panel will have a little icon in the tray
reminding you that a tomb is open, offering to explore it or close it.
Tomb generates 'key files' and protects them with a password choosen
by the user; the key files are then used to encrypt loop-back mounted
partitions, like single files containing a filesystem inside: this way
keys can be separated from data for safer transports when
required.
See the [[manual][manpage]] for more information on how to operate Tomb from the
commandline, also the back-end tool **tomb** comes complete with a brief
--help.
For more information on how to operate Tomb from the commandline, the
backend tool **tomb** comes complete with a brief --help and a
[[manual][manual page]].
** Downloads
@ -100,7 +101,7 @@ build your own application and as source code you can study.
*** Code repository
Latest stable release is 0.9 (25 January 2011) more about it in the
Latest stable release is 0.9 (28 January 2011) more about it in the
[[ftp://ftp.dyne.org/tomb/NEWS][NEWS]] and [[ftp://ftp.dyne.org/tomb/ChangeLog][ChangeLog]]
Source releases are checked and signed by [[http://jaromil.dyne.org][Jaromil]] using [[http://www.gnupg.org][GnuPG]].
@ -122,14 +123,30 @@ The bleeding edge version is developed on our [[http://code.dyne.org][code repos
*** Stage of development
Tomb is an evolution of the 'mknest' tool developed for the dyne:bolic
Tomb is an evolution of the 'mknest' tool developed for the [[http://dynebolic.org][dyne:bolic]]
GNU/Linux distribution, which is used by its 'nesting' mechanism to
encrypt the Home directory of users.
As such, it uses well tested and reviewed routines and its shell code
is pretty readable. The name transition from 'mknest' to 'tomb' is
marked by the adaptation of mknest to work on the Debian operating
system, used by its author in the past 3 years.
marked by the adaptation of mknest to work on Debian based operating
systems.
At present time Tomb is easy to install and use, it mainly consists of
a Shell script and some auxiliary C code for desktop integration
(GTK), making use of GNU tools and the cryptographic API of the Linux
kernel.
*** People involved
Tomb is designed and written by [[http://jaromil.dyne.org][Jaromil]]
Tomb's artwork is contributed by [[http://monmort.blogspot.org][Món Mort]]
Testing and fixes are contributed by Dreamer and Hellekin O. Wolf.
Tomb relies on Cryptsetup(8) and LUKS, big up to the developers involved \o/
*** How can you help
@ -142,3 +159,8 @@ Have a look in the TODO file to see what our plans are.
At the moment we can use some good help in porting this tool on
M$/Windows and Apple/OSX, still keeping the minimal approach we all
love.
Please report bugs on the tracker at http://bugs.dyne.org
Get in touch with developers via mail using this web page
http://dyne.org/contact or via chat on http://irc.dyne.org

1246
share/images/tomb_and_bats.xpm Normal file
View File

File diff suppressed because it is too large Load Diff

18
share/tomb-ascii-art.txt Normal file
View File

@ -0,0 +1,18 @@
,-------------------------------------------------.
,--. / Your tomb is open on loop3. Beware of zombies... )
( x o) (___________________________________________________/
\||| / hellekin's Tomb v0.2.1 2011-01-20 03:00:26 AM
,-------------------------------------------------.
,--. / Mr Carpenter needs to size ya for the coffin: )
( o O) ( How big do you want it? (in Mb) /
\||| /\_________________________________________________/
` ' ,--------------------------------------------------.
,-'. / Ye ain't gonna find any tomb without a name... )
( x x) (____________________________________________________/
\|:| / hellekin's Tomb v0.2.1 2011-01-20 03:00:26 AM

67
src/tomb
View File

@ -51,38 +51,69 @@ fi
# usb auto detect using dmesg
# tested on ubuntu 10.04 - please test and patch on other systems if you can
ask_usbkey() {
notice "looking for usb key"
notice "Waiting 1 minute for a usb key to connect"
echo -n " . please insert your usb key "
exec_as_user notify-send -i monmort \
-u normal -h string:App:Tomb \
-h double:Version:${VERSION} \
-t 60 \
"Insert your USB KEY" \
"Tomb is waiting 1 minute for you to insert an external key."
plugged=false
c=0
while [ "$plugged" != "true" ]; do
dmesg | tail -n 12 | grep -q 'new.*USB device'
if [ $? = 0 ]; then plugged=true; fi
echo -n "."
sleep .5
sleep 1
c=`expr $c + 1`
if [ $c -gt 60 ]; then
echo
error "timeout."
export usbkey_mount=none
return 1;
fi
done
echo
echo -n " . usb key inserted, opening "
c=0
attached=false
while [ "$attached" != "true" ]; do
dmesg | tail -n 3| grep -q 'Attached.*removable disk'
if [ $? = 0 ]; then attached=true; fi
echo -n "."
sleep .5
sleep 1
c=`expr $c + 1`
if [ $c -gt 15 ]; then
echo
error "timeout."
export usbkey_mount=none
return 1;
fi
done
# get the first partition
usbpart=`dmesg |tail -n 8 | grep ' sd.:' |cut -d: -f2 |tr -d ' '`
# wait that is mounted
c=0
mounted=false
while [ "$mounted" != "true" ]; do
cat /proc/mounts | tail -n 2 | grep -q $usbpart
if [ $? = 0 ]; then mounted=true; fi
echo -n "."
sleep .5
c=`expr $c + 1`
if [ $c -gt 30 ]; then
echo
error "timeout."
export usbkey_mount=none
return 1;
fi
done
# check where it is mounted
@ -171,8 +202,8 @@ while true; do
act ""
notice "Commands:"
act "create create a new encrypted storage FILE and keys"
act "mount mount an existing storage FILE on MOUNTPOINT"
act "umount unmounts a mounted storage MOUNTPOINT"
act "open open an existing tomb FILE on MOUNTPOINT"
act "close closes the tomb on MOUNTPOINT"
echo; exit 2 ;;
-v)
# print out the GPL license in this file
@ -248,29 +279,31 @@ fi
create_tomb() {
notice "Creating a new tomb in ${FILE}"
notice "Creating a new tomb"
if [ -z $SIZE ]; then
if [ $MOUNT ]; then
SIZE=$MOUNT
else
create_tomb_guided
# error "size is not specified, please use -s option when creating a tomb"
# exit 0
act "No size specified, summoning the Tomb Undertaker to guide us in the creation."
tomb-open &
disown
exit 0
fi
fi
# make sure the file has a .tomb extension
FILE="${FILE%\.*}.tomb"
SIZE_4k=`expr \( $SIZE \* 1000 \) / 4`
act "Generating file of ${SIZE}Mb (${SIZE_4k} blocks of 4Kb)"
# TODO: use dd_rescue and/or dcfldd
act "Generating ${FILE} of ${SIZE}Mb (${SIZE_4k} blocks of 4Kb)"
# TODO: use dd_rescue
$DD if=/dev/urandom bs=4k count=${SIZE_4k} of=${FILE}
# dd if=/dev/urandom bs=4k count=${SIZE_4k} of=${FILE}
if [ $? = 0 -a -e ${FILE} ]; then
act "OK: `ls -lh ${FILE}`"
else
error "Error creating the nest file ${FILE} : (dd if=/dev/zero of=${FILE} bs=4k count=$SIZE_4k)"
sleep 4
exit 0
error "Error creating the tomb ${FILE}, operation aborted."
exit 1
fi
mkdir -p /tmp/tomb
@ -321,7 +354,7 @@ create_tomb() {
read -q
if [ $? = 0 ]; then
ask_usbkey
if ! [ -w ${usbkey_mount} ]; then
if ! [ -e ${usbkey_mount} ]; then
error "cannot save the key in a separate place, move it yourself later."
else
mkdir -p ${usbkey_mount}/.tomb
@ -334,7 +367,7 @@ create_tomb() {
act "formatting your Tomb with Ext4 filesystem"
mkfs.ext4 -q -F -j -L "`hostname`-`date +%s`" /dev/mapper/tomb.tmp
mkfs.ext4 -q -F -j -L "${FILE%\.*}-`hostname`" /dev/mapper/tomb.tmp
if [ $? = 0 ]; then
act "OK, encrypted storage succesfully formatted"

2
src/tomb-open
View File

@ -95,7 +95,7 @@ Create a new Tomb
the computer you are using.
If you will, I'll be your Crypto Undertaker.
Do you want to proceed, Master? (y/n)"
Do you want to proceed, Master? (y/n)
EOF
echo -n "> "
read -q