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