mirror of
https://github.com/Llewellynvdm/Tomb.git
synced 2024-12-22 18:18:59 +00:00
629 lines
24 KiB
Groff
629 lines
24 KiB
Groff
.TH tomb 1 "Jun 25, 2023" "tomb"
|
|
|
|
.SH NAME
|
|
Tomb \- the Crypto Undertaker
|
|
|
|
.SH SYNOPSIS
|
|
.B
|
|
.IP "tomb [options] command [arguments]"
|
|
|
|
.SH DESCRIPTION
|
|
|
|
Tomb is an application to manage the creation and access of encrypted
|
|
storage files: it can be operated from commandline and it can
|
|
integrate with a user's graphical desktop.
|
|
|
|
Tomb generates encrypted storage files to be opened and closed using
|
|
their associated keys, which are also protected with a password chosen
|
|
by the user. To create, open and close tombs a user will need super
|
|
user rights to execute the tomb commandline utility.
|
|
|
|
A tomb is like a locked folder that can be safely transported and
|
|
hidden in a filesystem; it encourages users to keep their keys
|
|
separate from tombs, for instance keeping a tomb file on your computer
|
|
harddisk and its key file on a USB stick.
|
|
|
|
|
|
.SH COMMANDS
|
|
|
|
.B
|
|
.IP "dig"
|
|
Generates a file that can be used as a tomb and will occupy as much
|
|
space as its desired initial size, the unlocked \fI.tomb\fR file can
|
|
then be locked using a \fIkey\fR. It takes a mandatory \fI-s\fR option
|
|
which is the size in megabytes (MiB). Tombs are digged using random
|
|
data gathered from a non-blocking source (/dev/urandom). For very
|
|
large tombs this may take up too much time and entropy, then it is
|
|
possible to use \fIfallocate(1)\fR being aware it does not pre-fill
|
|
with random data, decreasing the tomb's security.
|
|
|
|
.B
|
|
.IP "forge"
|
|
Creates a new \fIkey\fR and prompts the user for a \fIpassword\fR to protect
|
|
its usage using symmetric encryption. This operation uses random data from a
|
|
non-blocking source (/dev/urandom) and it may take long only in some cases; to
|
|
switch using a blocking source the \fI--use-random\fR flag can be used. The
|
|
\fI-g\fR option switches on the use of a GPG key instead of a password
|
|
(asymmetric encryption), then the \fI-r\fR option indicates the recipient key;
|
|
more recipient GPG ids can be indicated (comma separated). The default cipher
|
|
to protect the key is AES256, a custom one can be specified using the \fI-o\fR
|
|
option, for a list of supported ciphers use \fI-v\fR. For additional protection
|
|
against dictionary attacks on keys, the \fI--kdf\fR option can be used when
|
|
forging a key, making sure that the binaries in \fIextras/kdf\fR were compiled
|
|
and installed on the system.
|
|
|
|
.B
|
|
.IP "lock"
|
|
Initializes and locks an empty tomb (made with \fIdig\fR) using a key
|
|
(made with \fIforge\fR), making it ready for usage. After this
|
|
operation, the tomb can only be opened in possession of the key and
|
|
knowing its password. As in any other command requiring a key, the
|
|
option \fI-k\fR should be used to specify a key file; in case of
|
|
encryption to GPG recipients the \fI-g\fR flag should be used followed
|
|
by \fI-r\fR and the recipient's secret GPG key id. The \fI-o\fR
|
|
option can be used to specify the cipher specification: default is
|
|
"aes-xts-plain64", old versions of Tomb used "aes-cbc-essiv:sha256".
|
|
If you are looking for something exotic, also try
|
|
"serpent-xts-plain64". More options may be found in cryptsetup(8) and
|
|
Linux documentation. The \fI--filesystem\fR option can be used to
|
|
specify an alternative filesystem used to format the tomb,
|
|
in place of the default "ext4". This operation requires root
|
|
privileges to loopback mount, format the tomb (using LUKS and mkfs),
|
|
then set the key in its first LUKS slot.
|
|
|
|
.RS
|
|
.nf
|
|
Supported filesystems for \fI--filesystem\fR:
|
|
"ext3" using operating system defaults
|
|
"ext4" using operating system defaults
|
|
"btrfs" for tombs >= 47MB using operating system defaults
|
|
"btrfsmixedmode" for tombs >=18MB btrfs mixed mode (see mkfs.btrfs(8))
|
|
"ext3maxinodes" ext3 with a maximum of inodes (for many small files)
|
|
"ext4maxinodes" ext4 with a maximum of inodes (for many small files)
|
|
.RE
|
|
|
|
.B
|
|
.IP "open"
|
|
Opens an existing \fItomb file\fR (first argument) using a key
|
|
(\fI-k\fR) which can also be hidden inside a \fIjpeg image\fR (see
|
|
\fIbury\fR/\fIexhume\fR) or a long text file
|
|
(see\fIcloak\fR/\fIuncloak\fR). If a second argument is given it will
|
|
indicate the \fImountpoint\fR where the tomb should be made
|
|
accessible, else the tomb is mounted in a directory inside /media (if
|
|
not available it uses /run/media/$USER). The option \fI-o\fR can be
|
|
used to pass mount(8) options (default: rw,noatime,nodev). The
|
|
\fI-g\fR option is needed when using GPG encryption to recipients.
|
|
|
|
.B
|
|
.IP "list"
|
|
List all the tombs found open, including information about the time
|
|
they were opened and the hooks that they mounted. If the first
|
|
argument is present, then shows only the tomb named that way or
|
|
returns an error if it's not found. If the option
|
|
\fI--get-mountpoint\fR is used then print a simple list of currently
|
|
open tomb mountpoint paths.
|
|
|
|
.B
|
|
.IP "ps"
|
|
List all the processes found running inside the tombs that are open,
|
|
printing out their PIDs and owners. This is useful to have an overview
|
|
of programs that are keeping the tombs busy and would eventually be
|
|
killed by the \fIslam\fR command. The lsof(8) utility is used
|
|
internally to enumerate processes running in one or all tombs.
|
|
|
|
.B
|
|
.IP "index"
|
|
Creates or updates the search indexes of all tombs currently open:
|
|
enables use of the \fIsearch\fR command using simple word patterns on
|
|
file names. Indexes are created using mlocate's updatedb(8) and
|
|
swish-e(1) if they are found on the system. Indexes allow one to search
|
|
very fast for filenames and contents inside a tomb, they are stored
|
|
inside it and are not accessible if the Tomb is closed. To avoid
|
|
indexing a specific tomb simply touch a \fI.noindex\fR file in it.
|
|
|
|
.B
|
|
.IP "search"
|
|
Takes any string as argument and searches for them through all tombs
|
|
currently open and previously indexed using the \fIindex\fR command.
|
|
The search matches filenames if mlocate is installed and then also
|
|
file contents if swish++ is present on the system, results are listed
|
|
on the console.
|
|
|
|
.B
|
|
.IP "close"
|
|
Closes a currently open tomb. If more tombs are open, the first
|
|
argument should be used to specify the name of the tomb to be closed,
|
|
or \fIall\fR to close all currently open tombs. This command fails if
|
|
the tomb is in use by running processes (to force close, see
|
|
\fIslam\fR below).
|
|
|
|
.B
|
|
.IP "slam"
|
|
Closes a tomb like the command \fIclose\fR does, but it doesn't fail
|
|
even if the tomb is in use by other application processes: it looks
|
|
for and closes each of them (in order: TERM, HUP, KILL). This command may
|
|
provoke unsaved data loss, but assists users to face surprise
|
|
situations. It requires \fIlsof\fR else it falls back to \fIclose\fR.
|
|
|
|
|
|
.B
|
|
.IP "passwd"
|
|
Changes the password protecting a key file specified using
|
|
\fI-k\fR. With keys encrypted for GPG recipients use \fI-g\fR followed
|
|
by \fI-r\fR to indicate the new recipient key, or a comma separated
|
|
list.. The user will need to know the key's current password, or
|
|
possess at least one of the current recipients GPG secret keys,
|
|
because the key contents will be decoded and reencoded using the new
|
|
passwords or keys. If the key file is broken (missing headers) this
|
|
function also attempts its recovery.
|
|
|
|
.B
|
|
.IP "setkey"
|
|
Changes the key file that locks a tomb, substituting the old one with
|
|
a new one. Both the old and the new key files are needed for this
|
|
operation and their passwords or GPG recipient(s) secret keys must be
|
|
available. The new key must be specified using the \fI-k\fR option,
|
|
the first argument should be the old key and the second and last
|
|
argument the tomb file. Use the \fI-g\fR option to unlock the tomb
|
|
with a GPG key, the \fI-r\fR to indicate the recipient or a comma
|
|
separated list for more than one recipient.
|
|
|
|
.B
|
|
.IP "resize"
|
|
Increase the size of a tomb file to the amount specified by the
|
|
\fI-s\fR option, which is the new size in megabytes (MiB). Full access
|
|
to the tomb using a key (\fI-k\fR) and its password is required. Tombs
|
|
can only grow and can never be made smaller. This command makes use of
|
|
the cryptsetup(8) resize feature and the resize2fs command: its much
|
|
more practical than creating a new tomb and moving everything into
|
|
it. There is no data-loss if a failure occurs during resize: the
|
|
command can be re-launched and the resize operation will complete.
|
|
|
|
.B
|
|
.IP "engrave"
|
|
This command transforms a tomb key into an image that can be printed
|
|
on paper and physically stored as backup, i.e. hidden in a book. It
|
|
Renders a QRCode of the tomb key, still protected by its password: a
|
|
PNG image (extension \fI.qr.png\fR) will be created in the current
|
|
directory and can be later printed (fits an A4 or Letter format). To
|
|
recover an engraved key one can use any QRCode reader on a smartphone:
|
|
save it into a file and then use that file as a key (\fI-k\fR).
|
|
|
|
.B
|
|
.IP "bury"
|
|
Hides a tomb key (\fI-k\fR) inside a \fIjpeg image\fR (first argument)
|
|
using \fIsteganography\fR: the image will change in a way that cannot
|
|
be noticed by human eye and hardly detected by data analysis. This
|
|
option is useful to backup tomb keys in unsuspected places; it depends
|
|
from the availability of \fIsteghide\fR. Use the \fI-g\fR flag and
|
|
\fI-r\fR option followed by recipient id to use GPG asymmetric
|
|
encryption.
|
|
|
|
.B
|
|
.IP "exhume"
|
|
This command recovers from jpeg images the keys that were previously
|
|
hidden into them using \fIbury\fR. Exhume requires a key filename
|
|
(\fI-k\fR) and a \fIjpeg image\fR file (first argument) known to be
|
|
containing a key. If the right key password is given, the key will be
|
|
exhumed. If the password is not known, it is very hard to verify if a
|
|
key is buried in any image or not.
|
|
|
|
.B
|
|
.IP "cloak"
|
|
Hides a tomb key (\fI-k\fR) inside a \fIlong plain-text file\fR (first
|
|
argument) using \fIsteganography\fR: the text will change in a way
|
|
that can hardly be noticed by human eye and hardly detected by data
|
|
analysis. This option is useful to backup tomb keys in unsuspected
|
|
places; it depends from the availability of \fIcloakify\fR and
|
|
consequently \fIpython2\fR. This function does not support asymmetric
|
|
encryption using the \fI-g\fR flag.
|
|
|
|
.B
|
|
.IP "uncloak"
|
|
This command recovers from long plain-text files the keys that were
|
|
previously hidden into them using \fIcloak\fR. Cloak requires a key
|
|
filename (\fI-k\fR) and a \fIplain-text\fR file (first argument) known
|
|
to be containing a key. If the right key password is given, the key
|
|
will be exhumed. If the password is not known, it is quite hard to
|
|
verify if a key is buried in a text or not.
|
|
|
|
.SH OPTIONS
|
|
.B
|
|
.B
|
|
.IP "-k \fI<keyfile>\fR"
|
|
For all operations requiring a key, this option specifies the location
|
|
of the key file to use. Arguments can also be \fIjpeg image\fR files
|
|
where keys have been hidden using the \fIbury\fR or \fIcloak\fR
|
|
commands, or text files retrieved from \fIengraved\fR QR codes. If the
|
|
\fIkeyfile\fR argument is "-" (dash), Tomb will read the key from
|
|
stdin (blocking).
|
|
.B
|
|
.IP "-n"
|
|
Skip processing of exec-hooks and bind-hooks if found inside the tomb.
|
|
See the \fIHOOKS\fR section in this manual for more information.
|
|
.B
|
|
.IP "-p"
|
|
When opening a tomb, preserves the ownership of all files and
|
|
directories contained in it. Normally the \fIopen\fR command changes
|
|
the ownership of a tomb's contents to the UID and GID of the user who
|
|
has successfully opened it: it is a usability feature in case a tomb is
|
|
used by a single user across different systems. This flag deactivates
|
|
this behaviour.
|
|
.B
|
|
.IP "-o"
|
|
Manually specify mount options to be used when opening a tomb instead
|
|
of the default \fIrw,noatime,nodev\fR, i.e. to mount a tomb read-only
|
|
(ro) to prevent any modification of its data. Can also be used to
|
|
change the symmetric encryption algorithm for keys during \fIforge\fR
|
|
operations (default \fIAES256\fR) or the LUKS encryption method during
|
|
\fIlock\fR operations (default \fIaes-xts-plain64\fR).
|
|
.B
|
|
.IP "-f"
|
|
Force flag, currently used to override swap checks, might be
|
|
overriding more wimpy behaviours in future, but make sure you know
|
|
what you are doing if you force an operation.
|
|
.B
|
|
.IP "-s \fI<MBytes>\fR"
|
|
When digging or resizing a tomb, this option must be used to specify
|
|
the \fIsize\fR of the new file to be created. Units are megabytes (MiB).
|
|
.B
|
|
.IP "-g"
|
|
Tell tomb to use a asymmetric GnuPG key encryption instead of a
|
|
symmetric passphrase to protect a tomb key. This option can be
|
|
followed by \fI-r\fR when the command needs to specify recipient(s).
|
|
.B
|
|
.IP "-r \fI<gpg_id>[,<gpg_id2>]\fR"
|
|
Provide a new set of recipient(s) to encrypt a tomb key. \fIgpg_ids\fR
|
|
can be one or more GPG key ID, comma separated. All GPG keys must be
|
|
trusted keys in GPG.
|
|
.B
|
|
.IP "--kdf \fI<itertime>\fR"
|
|
Activate the KDF feature against dictionary attacks when creating a key: forces
|
|
a delay of \fI<itertime>\fR times every time this key is used. The actual time
|
|
to wait depends on the CPU speed (default) or the RAM size (argon2) of the
|
|
computer where the key is used. Using 5 or 10 is a sane amount for modern
|
|
computers, the value is multiplied by 1 million.
|
|
.B
|
|
.IP "--kdftype \fIargon2 | pbkdf2\fR"
|
|
Adopt the \fIargon2\fR algorithm for KDF, stressing the RAM capacity rather
|
|
than the CPU speed of the computer decrypting the tomb. Requires the
|
|
\fIargon2\fR binary by P-H-C to be installed, as packaged by most distros.
|
|
Default is \fIpbkdf2\fR.
|
|
.B
|
|
.IP "--kdfmem \fI<memory>\fR"
|
|
In case of \fIargon2\fR KDF algorithm, this value specifies the size of RAM
|
|
used: it consists of a number which is the elevated power of two in kilobytes.
|
|
Default is 18 which is 250 MiB (2^18 = 262,144 kilobytes).
|
|
.B
|
|
.IP "--sudo \fI<executable>\fR"
|
|
Select a different tool than sudo for privilege escalation.
|
|
Alternatives supported so far are: pkexec, doas, sup, sud. For any
|
|
alternative to work the executable must be included in the current
|
|
PATH.
|
|
.B
|
|
.IP "--sphx-user \fI<username>\fR"
|
|
Activate the SPHINX feature for password-authenticated key agreement.
|
|
This option indicates the \fI<username>\fR used to retrieve the
|
|
password from a sphinx oracle key reachable via TCP/IP.
|
|
.B
|
|
.IP "--sphx-host \fI<domain>\fR"
|
|
Activate the SPHINX feature for password-authenticated key agreement.
|
|
This option indicates the \fI<domain>\fR used to retrieve the password
|
|
from a sphinx oracle daemon reachable via TCP/IP. This is not the
|
|
network address of the daemon, which is configured in /etc/sphinx
|
|
|
|
.B
|
|
.IP "-h"
|
|
Display a help text and quit.
|
|
.B
|
|
.IP "-v"
|
|
Display version and quit.
|
|
.B
|
|
.IP "-q"
|
|
Run more quietly
|
|
.B
|
|
.IP "-D"
|
|
Print more information while running, for debugging purposes
|
|
|
|
.SH DEV MODE
|
|
.B
|
|
.IP "--no-color"
|
|
Suppress colors in console output (needed for string parsing by
|
|
wrappers).
|
|
.B
|
|
.IP "--unsafe"
|
|
Enable using dev-mode arguments, i.e. to pass passwords from
|
|
commandline options. This is mostly used needed for execution by
|
|
wrappers and testing suite.
|
|
.B
|
|
.IP "--use-random"
|
|
Use a blocking random source. Tomb uses by default /dev/urandom since
|
|
the non-blocking source of Linux kernel doesn't degrades the quality
|
|
of random.
|
|
.B
|
|
.IP "--tomb-pwd <string>"
|
|
Use string as password when needed on tomb.
|
|
.B
|
|
.IP "--tomb-old-pwd <string>"
|
|
Use string as old password when needed in tomb commands requiring
|
|
multiple keys, like \fIpasswd\fR or \fIsetkey\fR.
|
|
.B
|
|
.IP "-U"
|
|
Switch to this user ID when dropping privileges.
|
|
.B
|
|
.IP "-G"
|
|
Switch to this group ID when dropping privileges.
|
|
.B
|
|
.IP "-T"
|
|
Switch to this TTY terminal when dropping privileges.
|
|
|
|
.SH HOOKS
|
|
|
|
Hooks are special files that can be placed inside the tomb and trigger
|
|
actions when it is opened and closed; there are two kinds of such
|
|
files: \fIbind-hooks\fR and \fIexec-hooks\fR can be placed in the
|
|
base root of the tomb.
|
|
|
|
.B
|
|
.IP "bind-hooks"
|
|
This hook file consists of a simple text file named \fIbind-hooks\fR
|
|
containing a two column list of paths to files or directories inside
|
|
the tomb. The files and directories will be be made directly
|
|
accessible by the tomb \fIopen\fR command inside the current user's
|
|
home directory. Tomb uses internally the "mount \-o bind" command to
|
|
bind locations inside the tomb to locations found in $HOME. In the
|
|
first column are indicated paths relative to the tomb and in the
|
|
second column are indicated paths relative to $HOME contents, for
|
|
example:
|
|
.EX
|
|
mail mail
|
|
.gnupg .gnupg
|
|
.fmrc .fetchmailrc
|
|
.mozilla .mozilla
|
|
.EE
|
|
|
|
.B
|
|
.IP "exec-hooks"
|
|
This hook file gets executed as user by tomb with the first argument
|
|
determining the step of execution (\fIopen\fR or \fIclose\fR) and the second
|
|
being the full path to the mountpoint. The \fIexec-hooks\fR file should be
|
|
executable (ELF or shell script) and present inside the Tomb. Tomb
|
|
executes this hook as user and adds the name, loopback device and
|
|
dev-mapper device paths as additional arguments for the \fIclose\fR
|
|
command.
|
|
|
|
.SH PRIVILEGE ESCALATION
|
|
|
|
The tomb commandline tool needs to acquire super user rights to
|
|
execute most of its operations: so it uses sudo(8) or other configured
|
|
tools, while pinentry(1) is adopted to collect passwords from the
|
|
user. Tomb executes as super user only when required.
|
|
|
|
To be made available on multi user systems, the superuser execution of
|
|
the tomb script can be authorized for users without jeopardizing the
|
|
whole system's security: just add such a line to \fI/etc/sudoers\fR:
|
|
|
|
.EX
|
|
username ALL=NOPASSWD: /usr/local/bin/tomb
|
|
.EE
|
|
|
|
To avoid that tomb execution is logged by \fIsyslog\fR also add:
|
|
|
|
.EX
|
|
Cmnd_Alias TOMB = /usr/local/bin/tomb
|
|
Defaults!TOMB !syslog
|
|
.EE
|
|
|
|
.SH PASSWORD INPUT
|
|
|
|
Password input is handled by the pinentry program: it can be text
|
|
based or graphical and is usually configured with a symlink. When
|
|
using Tomb in X11 it is better to use a graphical pinentry-gtk2 or
|
|
pinentry-qt because it helps preventing keylogging by other X
|
|
clients. When using it from a remote ssh connection it might be
|
|
necessary to force use of pinentry-curses for instance by unsetting
|
|
the DISPLAY environment var.
|
|
|
|
|
|
.SH SWAP
|
|
|
|
On execution of certain commands Tomb will complain about swap memory
|
|
on disk when present and \fIabort if your system has swap
|
|
activated\fR. You can disable this behaviour using the
|
|
\fI--force\fR. Before doing that, however, you may be interested in
|
|
knowing the risks of doing so:
|
|
.IP \(bu
|
|
During such operations a lack of available memory could cause the swap
|
|
to write your secret key on the disk.
|
|
.IP \(bu
|
|
Even while using an opened tomb, another application could occupy too
|
|
much memory so that the swap needs to be used, this way it is possible
|
|
that some contents of files contained into the tomb are physically
|
|
written on your disk, not encrypted.
|
|
.P
|
|
|
|
If you don't need swap, execute \fI swapoff -a\fR. If you really need
|
|
it, you could make an encrypted swap partition. Tomb doesn't detect if
|
|
your swap is encrypted, and will complain anyway.
|
|
|
|
.SH DENIABILITY
|
|
|
|
The possibility to have an encrypted volume which is invisible and
|
|
cannot be detected is called "deniability". The cryptographic layer of
|
|
the device mapper in Linux (dm-crypt) does not implement
|
|
deniability. Tomb is just a wrapper on top of that and it doesn't add
|
|
cryptographic deniability. However a certain way of using tomb can
|
|
facilitate a weak sort of deniability outside of the scenario of
|
|
seized devices and forensic analysis of files and blocks on disc.
|
|
|
|
For instance to eliminate any trace of tomb usage from the shell
|
|
history ZSh users can activate the "HISTIGNORESPACE" feature and
|
|
prefix all invocations of tomb with a blank space, including two lines
|
|
in ".zshrc":
|
|
|
|
.EX
|
|
export HISTIGNORESPACE=1
|
|
alias tomb=' tomb'
|
|
.EE
|
|
|
|
.SH PASSWORD INPUT
|
|
|
|
Tomb uses the external program "pinentry" to let users type the key password into a terminal or a graphical window. This program works in conjunction with "gpg-agent", a daemon running in background to facilitate secret key management with gpg. It is recommended one runs "gpg-agent" launching it from the X session initialization ("~/.xsession" or "~/.xinitrc" files) with this command:
|
|
|
|
.EX
|
|
eval $(gpg-agent --daemon --write-env-file "${HOME}/.gpg-agent-info")
|
|
.EE
|
|
|
|
In the future it may become mandatory to run gpg-agent when using tomb.
|
|
|
|
.SH SHARE A TOMB
|
|
A tomb key can be encrypted with more than one recipient. Therefore, a
|
|
tomb can be shared between different users. The recipients are given
|
|
using the \fI-r\fR (or/and \fI-R\fR) option and if multiple each GPG
|
|
key ID must be separated by a comma (\fI,\fR). Sharing a tomb is a
|
|
very sensitive action and the user needs to trust that all the GPG
|
|
public keys used are kept safe. If one of them its stolen or lost, it
|
|
will be always possible to use it to access the tomb key unless all
|
|
its copies are destroyed. The \fI-r\fR option can be used in the tomb
|
|
commands: \fIopen\fR, \fIforge\fR \fIsetkey\fR, \fIpasswd\fR,
|
|
\fIbury\fR, \fIexhume\fR and \fIresize\fR.
|
|
|
|
.SH SPHINX (PAKE)
|
|
|
|
Using the package libsphinx
|
|
.UR https://github.com/stef/libsphinx
|
|
.UE
|
|
and its python client/daemon implementation pwdsphinx
|
|
.UR https://github.com/stef/pwdsphinx
|
|
.UE
|
|
is possible to store and retrieve safely the password that locks the
|
|
tomb. Using this feature will make it impossible to retrieve the
|
|
password without the oracle sphinx server running and reachable. Each
|
|
key entry needs a username and a domain specified on creation and
|
|
a password that locks it.
|
|
|
|
SPHINX makes it impossible to maliciously retrieve the password
|
|
locking the tomb key without an attacker accessing both the
|
|
server, the sphinx password and the tomb key file.
|
|
|
|
.SH EXAMPLES
|
|
|
|
.IP \(bu
|
|
Create a 128MB large "secret" tomb and its keys, then open it:
|
|
|
|
.EX
|
|
tomb dig -s 128 secret.tomb
|
|
|
|
tomb forge secret.tomb.key
|
|
|
|
tomb lock secret.tomb -k secret.tomb.key
|
|
|
|
tomb open secret.tomb -k secret.tomb.key
|
|
.EE
|
|
|
|
.IP \(bu
|
|
Open a Tomb using the key from a remote SSH shell, without saving any
|
|
local copy of it:
|
|
|
|
.EX
|
|
ssh user@my.shell.net 'cat .secrets/tomb.key' | tomb open secret.tomb -k -
|
|
.EE
|
|
|
|
.IP \(bu
|
|
Open a Tomb on a remote server passing the unencrypted local key on stdin via SSH,
|
|
without saving any remote copy of it:
|
|
|
|
.EX
|
|
gpg -d .secrets/tomb.key | ssh server tomb open secret.tomb -k cleartext --unsafe
|
|
.EE
|
|
|
|
.IP \(bu
|
|
Create a bind hook that places your GnuPG folder inside the tomb, but
|
|
makes it reachable from the standard $HOME/.gnupg location every time
|
|
the tomb will be opened:
|
|
|
|
.EX
|
|
tomb open GPG.tomb -k GPG.tomb.key
|
|
echo ".gnupg .gnupg" > /media/GPG.tomb/bind-hooks
|
|
mv ~/.gnupg /media/GPG.tomb/.gnupg && mkdir ~/.gnupg
|
|
tomb close GPG && tomb open GPG.tomb -k GPG.tomb.key
|
|
.EE
|
|
|
|
.IP \(bu
|
|
Script a tomb to launch the Firefox browser every time is opened,
|
|
keeping all its profile data inside it:
|
|
|
|
.EX
|
|
tomb open FOX.tomb -k FOX.tomb.key
|
|
cat <<EOF > /media/FOX.tomb/exec-hooks
|
|
#!/bin/sh
|
|
if [ "$1" = "open" ]; then
|
|
firefox -no-remote -profile "$2"/firefox-pro &
|
|
fi
|
|
EOF
|
|
chmod +x /media/FOX.tomb/exec-hooks
|
|
mkdir /media/FOX.tomb/firefox-pro
|
|
.EE
|
|
|
|
.IP \(bu
|
|
Script a tomb to archive Pictures using Shotwell, launching it on open:
|
|
|
|
.EX
|
|
tomb open Pictures.tomb -k Pictures.tomb.key
|
|
cat <<EOF > /media/Pictures.tomb/bind-hooks
|
|
Pictures Pictures
|
|
EOF
|
|
cat <<EOF > /media/Pictures.tomb/exec-hooks
|
|
#!/bin/sh
|
|
if [ "$1" = "open" ]; then
|
|
which shotwell > /dev/null
|
|
if [ "$?" = "0" ]; then
|
|
shotwell -d "$2"/Pictures/.shotwell &
|
|
fi
|
|
fi
|
|
EOF
|
|
chmod +x /media/Pictures.tomb/exec-hooks
|
|
.EE
|
|
|
|
.SH BUGS
|
|
Please report bugs on the Github issue tracker at
|
|
.UR https://github.com/dyne/Tomb/issues
|
|
.UE
|
|
|
|
One can also try to get in touch with developers via the #dyne chat
|
|
channel on \fIhttps://irc.dyne.org\fR.
|
|
|
|
.SH COPYING
|
|
|
|
This manual is Copyright (c) 2011-2021 by Denis Roio <\fIjaromil@dyne.org\fR>
|
|
|
|
This manual includes contributions by Boyska and Hellekin O. Wolf.
|
|
|
|
Permission is granted to copy, distribute and/or modify this manual
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
|
any later version published by the Free Software Foundation.
|
|
Permission is granted to make and distribute verbatim copies of this
|
|
manual page provided the above copyright notice and this permission
|
|
notice are preserved on all copies.
|
|
|
|
.SH AVAILABILITY
|
|
|
|
The most recent version of Tomb sourcecode and up to date
|
|
documentation is available for download from its website on
|
|
\fIhttps://tomb.dyne.org\fR.
|
|
|
|
.SH SEE ALSO
|
|
|
|
.B
|
|
.IP cryptsetup(8)
|
|
.B
|
|
.IP pinentry(1)
|
|
.B
|
|
.IP gpg-agent(1)
|
|
|
|
GnuPG website: https://www.gnupg.org
|
|
|
|
DM-Crypt website: https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
|
|
|
|
LUKS website: https://gitlab.com/cryptsetup/cryptsetup/wikis/home
|