[pass] ctmg: bash script for secure encrypted containers

[Emil Lundberg]

Heh, looks like there was more than just something in particular. Great
response! With this in mind I just might move over to ctmg after I've tried
it out a bit. I agree that the small amount of code is an important feature
in and of itself.

Cheers,
Emil

On Wed, 9 Mar 2016, 17:46 Jason A. Donenfeld, <Jason at zx2c4.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20160309/a518397f/attachment.html>