[pass] ctmg: bash script for secure encrypted containers
Jason A. Donenfeld
Jason at zx2c4.com
Wed Mar 9 17:46:26 CET 2016
LUKS already does PBKDF2 to passphrases. What is the purpose of the
additional GnuPG symmetric wrapping used by Tomb? Or their
reimplementation wrapper of it using gcrypt? More moving parts, more
files to loose, more places to break. For example, the bugs page says
"This bug was due to a typo in the code which appended a GnuPG status
string to the content of keys." Ugh. The whole design seems needlessly
complex for what I'd like, and the "bury" and "exhume" features smell
of bloat -- somebody writing ZSH who didn't know when to stop. I also
don't have zsh installed and have no intention of installing it. Every
single command is called with sudo which bloats my syslog. The authors
on their site recommend storing a tomb on a remote share, which
demonstrates they don't understand the risks and limitations of
XTS-mode. It looks like not only have they failed to study the entire
`cryptsetup` man page and related LUKS documentation, but also lack
basic cryptography education. So.... I'd stay away if I were you. Read
the 172 lines of ctmg, understand each one, read the man pages of the
commands that are used (basically just cryptsetup), and sleep well at
night. The only important difference between the two that you might
desire in ctmg is that rather than allocating massive files, I use
sparse allocation (using truncate(1)), whereas tomb fills with random
data. What I use makes the actual allocation happen on demand, which
is more resource friendly, but enables an attacker to estimate
container space utilization. You could pretty easily change the call
to truncate on line 96 with a call to dd if=/dev/urandom if you'd like
the containers to be filled with random data.
More information about the Password-Store
mailing list