tmanpage, documentation and fixes for the new release - tomb - the crypto undertaker
HTML git clone git://parazyd.org/tomb.git
DIR Log
DIR Files
DIR Refs
DIR README
DIR LICENSE
---
DIR commit eac4818f30b834abb50bd7a375a134de049a58ed
DIR parent 85fe9295bdfaf4757bb11db1d2f7f345bad590c6
HTML Author: Jaromil <jaromil@dyne.org>
Date: Fri, 28 Jan 2011 12:26:35 +0100
manpage, documentation and fixes for the new release
includes also timeout to ask_usbkey, correct naming of tomb
reference documentation for encryption settings, webpage updates and artworks
Diffstat:
M .gitignore | 10 ++++++++--
M AUTHORS | 6 +++++-
M ChangeLog | 5 +++++
A README.muse | 133 +++++++++++++++++++++++++++++++
A doc/LinuxHDEncSettings.txt | 404 +++++++++++++++++++++++++++++++
M doc/tomb.1 | 2 +-
A doc/web/views/images/monmort.png | 0
A doc/web/views/images/tomb_n_bats.p… | 0
M doc/web/views/index.muse | 56 +++++++++++++++++++++----------
A share/images/tomb_and_bats.xpm | 1246 +++++++++++++++++++++++++++++++
A share/tomb-ascii-art.txt | 18 ++++++++++++++++++
M src/tomb | 69 +++++++++++++++++++++++--------
M src/tomb-open | 2 +-
13 files changed, 1911 insertions(+), 40 deletions(-)
---
DIR diff --git a/.gitignore b/.gitignore
t@@ -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
t@@ -22,3 +25,6 @@ Makefile.in
missing
stamp-h1
tags
+doc/web/public
+doc/web/dyne
+
DIR diff --git a/AUTHORS b/AUTHORS
t@@ -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.
+
DIR diff --git a/ChangeLog b/ChangeLog
t@@ -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
DIR diff --git a/README.muse b/README.muse
t@@ -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.
DIR diff --git a/doc/LinuxHDEncSettings.txt b/doc/LinuxHDEncSettings.txt
t@@ -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/
DIR diff --git a/doc/tomb.1 b/doc/tomb.1
t@@ -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
DIR diff --git a/doc/web/views/images/monmort.png b/doc/web/views/images/monmort.png
Binary files differ.
DIR diff --git a/doc/web/views/images/tomb_n_bats.png b/doc/web/views/images/tomb_n_bats.png
Binary files differ.
DIR diff --git a/doc/web/views/index.muse b/doc/web/views/index.muse
t@@ -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
t@@ -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
t@@ -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]].
t@@ -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
t@@ -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
DIR diff --git a/share/images/tomb_and_bats.xpm b/share/images/tomb_and_bats.xpm
t@@ -0,0 +1,1246 @@
+/* XPM */
+static char *tomb_and_bats[] = {
+/* columns rows colors chars-per-pixel */
+"984 984 256 2",
+" c #000000",
+". c #010101",
+"X c #020202",
+"o c #030303",
+"O c #040404",
+"+ c #050505",
+"@ c #060606",
+"# c #070707",
+"$ c #080808",
+"% c #090909",
+"& c #0A0A0A",
+"* c #0B0B0B",
+"= c #0C0C0C",
+"- c #0D0D0D",
+"; c #0E0E0E",
+": c #0F0F0F",
+"> c #101010",
+", c #111111",
+"< c #121212",
+"1 c #131313",
+"2 c #141414",
+"3 c #151515",
+"4 c #161616",
+"5 c #171717",
+"6 c #181818",
+"7 c #191919",
+"8 c #1A1A1A",
+"9 c #1B1B1B",
+"0 c #1C1C1C",
+"q c #1D1D1D",
+"w c #1E1E1E",
+"e c #1F1F1F",
+"r c #202020",
+"t c #212121",
+"y c #222222",
+"u c #232323",
+"i c #242424",
+"p c #252525",
+"a c #262626",
+"s c #272727",
+"d c #282828",
+"f c #292929",
+"g c #2A2A2A",
+"h c #2B2B2B",
+"j c #2C2C2C",
+"k c #2D2D2D",
+"l c #2E2E2E",
+"z c #2F2F2F",
+"x c #303030",
+"c c #313131",
+"v c #323232",
+"b c #333333",
+"n c #343434",
+"m c #353535",
+"M c #363636",
+"N c #373737",
+"B c #383838",
+"V c #393939",
+"C c #3A3A3A",
+"Z c #3B3B3B",
+"A c #3C3C3C",
+"S c #3D3D3D",
+"D c #3E3E3E",
+"F c #3F3F3F",
+"G c #404040",
+"H c #414141",
+"J c #424242",
+"K c #434343",
+"L c #444444",
+"P c #454545",
+"I c #464646",
+"U c #474747",
+"Y c #484848",
+"T c #494949",
+"R c #4A4A4A",
+"E c #4B4B4B",
+"W c #4C4C4C",
+"Q c #4D4D4D",
+"! c #4E4E4E",
+"~ c #4F4F4F",
+"^ c #505050",
+"/ c #515151",
+"( c #525252",
+") c #535353",
+"_ c #545454",
+"` c #555555",
+"' c #565656",
+"] c #575757",
+"[ c #585858",
+"{ c #595959",
+"} c #5A5A5A",
+"| c #5B5B5B",
+" . c #5C5C5C",
+".. c #5D5D5D",
+"X. c #5E5E5E",
+"o. c #5F5F5F",
+"O. c #606060",
+"+. c #616161",
+"@. c #626262",
+"#. c #636363",
+"$. c #646464",
+"%. c #656565",
+"&. c #666666",
+"*. c #676767",
+"=. c #686868",
+"-. c #696969",
+";. c #6A6A6A",
+":. c #6B6B6B",
+">. c #6C6C6C",
+",. c #6D6D6D",
+"<. c #6E6E6E",
+"1. c #6F6F6F",
+"2. c #707070",
+"3. c #717171",
+"4. c #727272",
+"5. c #737373",
+"6. c #747474",
+"7. c #757575",
+"8. c #767676",
+"9. c #777777",
+"0. c #787878",
+"q. c #797979",
+"w. c #7A7A7A",
+"e. c #7B7B7B",
+"r. c #7C7C7C",
+"t. c #7D7D7D",
+"y. c #7E7E7E",
+"u. c #7F7F7F",
+"i. c #808080",
+"p. c #818181",
+"a. c #828282",
+"s. c #838383",
+"d. c #848484",
+"f. c #858585",
+"g. c #868686",
+"h. c #878787",
+"j. c #888888",
+"k. c #898989",
+"l. c #8A8A8A",
+"z. c #8B8B8B",
+"x. c #8C8C8C",
+"c. c #8D8D8D",
+"v. c #8E8E8E",
+"b. c #8F8F8F",
+"n. c #909090",
+"m. c #919191",
+"M. c #929292",
+"N. c #939393",
+"B. c #949494",
+"V. c #959595",
+"C. c #969696",
+"Z. c #979797",
+"A. c #989898",
+"S. c #999999",
+"D. c #9A9A9A",
+"F. c #9B9B9B",
+"G. c #9C9C9C",
+"H. c #9D9D9D",
+"J. c #9E9E9E",
+"K. c #9F9F9F",
+"L. c #A0A0A0",
+"P. c #A1A1A1",
+"I. c #A2A2A2",
+"U. c #A3A3A3",
+"Y. c #A4A4A4",
+"T. c #A5A5A5",
+"R. c #A6A6A6",
+"E. c #A7A7A7",
+"W. c #A8A8A8",
+"Q. c #A9A9A9",
+"!. c #AAAAAA",
+"~. c #ABABAB",
+"^. c #ACACAC",
+"/. c #ADADAD",
+"(. c #AEAEAE",
+"). c #AFAFAF",
+"_. c #B0B0B0",
+"`. c #B1B1B1",
+"'. c #B2B2B2",
+"]. c #B3B3B3",
+"[. c #B4B4B4",
+"{. c #B5B5B5",
+"}. c #B6B6B6",
+"|. c #B7B7B7",
+" X c #B8B8B8",
+".X c #B9B9B9",
+"XX c #BABABA",
+"oX c #BBBBBB",
+"OX c #BCBCBC",
+"+X c #BDBDBD",
+"@X c #BEBEBE",
+"#X c #BFBFBF",
+"$X c #C0C0C0",
+"%X c #C1C1C1",
+"&X c #C2C2C2",
+"*X c #C3C3C3",
+"=X c #C4C4C4",
+"-X c #C5C5C5",
+";X c #C6C6C6",
+":X c #C7C7C7",
+">X c #C8C8C8",
+",X c #C9C9C9",
+"<X c #CACACA",
+"1X c #CBCBCB",
+"2X c #CCCCCC",
+"3X c #CDCDCD",
+"4X c #CECECE",
+"5X c #CFCFCF",
+"6X c #D0D0D0",
+"7X c #D1D1D1",
+"8X c #D2D2D2",
+"9X c #D3D3D3",
+"0X c #D4D4D4",
+"qX c #D5D5D5",
+"wX c #D6D6D6",
+"eX c #D7D7D7",
+"rX c #D8D8D8",
+"tX c #D9D9D9",
+"yX c #DADADA",
+"uX c #DBDBDB",
+"iX c #DCDCDC",
+"pX c #DDDDDD",
+"aX c #DEDEDE",
+"sX c #DFDFDF",
+"dX c #E0E0E0",
+"fX c #E1E1E1",
+"gX c #E2E2E2",
+"hX c #E3E3E3",
+"jX c #E4E4E4",
+"kX c #E5E5E5",
+"lX c #E6E6E6",
+"zX c #E7E7E7",
+"xX c #E8E8E8",
+"cX c #E9E9E9",
+"vX c #EAEAEA",
+"bX c #EBEBEB",
+"nX c #ECECEC",
+"mX c #EDEDED",
+"MX c #EEEEEE",
+"NX c #EFEFEF",
+"BX c #F0F0F0",
+"VX c #F1F1F1",
+"CX c #F2F2F2",
+"ZX c #F3F3F3",
+"AX c #F4F4F4",
+"SX c #F5F5F5",
+"DX c #F6F6F6",
+"FX c #F7F7F7",
+"GX c #F8F8F8",
+"HX c #F9F9F9",
+"JX c #FAFAFA",
+"KX c #FBFBFB",
+"LX c #FCFCFC",
+"PX c #FDFDFD",
+"IX c #FFFFFF",
+"UX c None",
+/* pixels */
parazyd.org:70 /git/tomb/commit/eac4818f30b834abb50bd7a375a134de049a58ed.gph:1007: line too long