Hacker News Reader

Comment by sillysaurus | Hacker News Reader

Why not just store a TrueCrypt volume(s) in Dropbox?

Because TrueCrypt is not exactly "free and open source" software either.

http://en.wikipedia.org/wiki/Truecrypt#Reasonable_paranoia

"""It is challenging to create binaries from source code that match the official binaries bit-by-bit for purposes of verifying their integrity due to compiler options

...

There has been no known comprehensive review of the source code by a qualified cryptographer.[46][44] Thorough security code review and testing is hard, tedious, and painstaking work, and very few people have the skills to do it. There was, however, a functional evaluation of the deniability of hidden volumes in an earlier version of TrueCrypt by Schneier et al. that found security leaks.[47]"""

This is assuming the Government doesn't force Dropbox to install a keylogger on their client to get users TrueCrypt passphrases and possibly keyfiles.

If Dropbox bundled a keylogger with the Dropbox client, I'm pretty sure it would eventually attract some attention...

Yeah, 4 years later when a whistle blower said something.

Who's to say they can't be convinced to push a one-off update to your account/machine. Perhaps a transitory one, to help cover their tracks?

The underlying problem is that you're trusting closed client software from a third-party. Once that is running on your system, arguably it's game over as far as what Dropbox or its like can and can't do to you.

(If you trust them, ok. But when documents state that "they're next", many of us start to wonder. And again, this isn't just access to a server. Through their client software, this is access to your machine, that you've already granted.

Admittedly, I'm describing the typical Dropbox user scenario and not where the client is manually applying -- or not -- each update, and somehow supposedly gaining insight into the capabilities of each update/version before doing so. And I'm also ignoring various forms of restricting the access of the Dropbox client, although if they really want you, they and parties using them would have extensive resources to apply to breaking out of such constraints.)

https://grepular.com/Protecting_Your_GNU_Linux_System_from_D...

Thank you. I will read through this.

Let me take the opportunity to also thank you for writing up your email best practices. I hope to implement them or something similar for myself.

One of the challenges for me in all this is keeping up including with the implementation details. It feels akin to swimming upstream, with the current outpacing me.

Very interesting and useful, not just for securing DropBox either.

FYI this article suggests to use encfs for an encrypted folder in your dropbox, this comment https://news.ycombinator.com/item?id=5855465 suggests that this might not be a wise choice, so you might want to (re)consider that part.

Storing an EncFS on Dropbox is another alternative, that doesn't depend on Dropbox' ability to recognize small changes in a huge single file.

It'd be better to use EncFS in this case, as it does per-file encryption. With TruCrypt, the whole volume file would need updating once you unmount it, if I understand correctly.

I like Boxcryptor since it encrypts each file individually rather than the whole volume. However, the file names are exposed.

encfs. Encrypts each file individually and file name are encrypted.

encfs sometimes generates very long path names, which runs against the 255-char limit that Dropbox imposes if you have any Windows computers linked to your account. Last time I tried it, the filenames were silently corrupted and much data was lost.

That's what I do, I have a small (100 MB) small volume sync in my DB, works like a charm :)

Because, as far as I know (I haven't used TrueCrypt too much), it will see the volume as a file and then you'll be syncing a huge, x GB file every time you make the smallest change within it.

That's not true. Dropbox uses librsync so small changes of big files yields small diffs, thus TrueCrypt volumes work just fine with Dropbox.

Speaking out of ignorance here: But aren't TrueCrypt volumes completely changed when you add/remove something? I'm thinking similarly to a hash: The slightest modification changes it completely.

That's not how it works - it would be inefficient to the point of uselessness to rewrite the entire file constantly, and my 100GB TrueCrypt volume is fast to save to.

If that were the case, then terabyte-scale volumes would be prohibitively useless - and I know plenty of people with media volumes in TC.

But aren't TrueCrypt volumes completely changed when you add/remove something?

No, the crypto in TrueCrypt doesn't amplify the number of changed blocks. But it does disperse the changed blocks throughout the encrypted image, and this does result in higher bandwidth used during the sync (at least with DropBox). Here's an analysis I did a few years ago:

https://news.ycombinator.com/item?id=2546626

Reply on news.ycombinator.com