3 ms·

Encrypt with Truecrypt, share with Dropbox. Problem solved.

by armored 15y ago

rdl 15y ago
Except then you can't use those files on mobile devices or from the web UI, both of which are useful (my primary interest in dropbox, and the one thing I can't trivially accomplish on my own, is the iOS device support. The alternative is just to use Apple's iDisk, which has exactly the same risks as Dropbox, minus the cross-platform capabilities.)
- armored 15y ago
  I'm not sure if it's helpful to you, but I use Keypass & Dropbox to sync some encrypted data to my Android phone. It's limited but useful for storing sensitive text. There is an iPhone app: http://ikeepass.de/ http://ikeepass.de/
  - rdl 15y ago
    I use 1password and wifi syncing. I asked them to add WebDAV support to store the bundle, which is how omnifocus does this, which is probably the most cloudiness I will accept for my password file.
sigil 15y ago
> Encrypt with Truecrypt, share with Dropbox. Problem solved. Not so fast. How big is the binary diff when you change a file within a Truecrypt volume? Ie, how much Dropbox bandwidth will you be using, even with a small change? I performed the following experiment. Start with a 250M Truecrypt volume. Mount it. Create a 1M file from /dev/random. Unmount the volume. Now, look at what blocks in the Truecrypt volume file have changed. Dropbox uses a 4M blocksize [1]. seq 0 63 | while read i; do { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.before | md5sum done 2>/dev/null | sort > md5s.before seq 0 63 | while read i; do { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.after | md5sum done 2>/dev/null | sort > md5s.after comm -13 md5s.before md5s.after | wc -l 8 Conclusion: in this case, Dropbox will transfer 32M (8x the normal 4M) because I added a 1M file to my Truecrypt volume. Note: I haven't tried adding bigger files, but suspect the number of blocks changed will go up linearly but steeply with the size of the added file. It's not actually that surprising that TrueCrypt mixes file changes throughout the volume file. Why bring this all up? Because something that does client side block encryption (tarsnap is an example) would only transfer the affected block. 4M, if that's the block size. And you don't have to trust the cloud storage provider at all. EDIT: My pipelines were wrong on the first go, suggesting a much larger number of differing blocks. Sorry about that. [1] http://forums.dropbox.com/topic.php?id=17631 http://forums.dropbox.com/topic.php?id=17631

Encrypt with Truecrypt, share with Dropbox. Problem solved.

by armored 15y ago

Encrypt with Truecrypt, share with Dropbox. Problem solved.

rdl 15y ago

Except then you can't use those files on mobile devices or from the web UI, both of which are useful (my primary interest in dropbox, and the one thing I can't trivially accomplish on my own, is the iOS device support. The alternative is just to use Apple's iDisk, which has exactly the same risks as Dropbox, minus the cross-platform capabilities.)

armored 15y ago
I'm not sure if it's helpful to you, but I use Keypass & Dropbox to sync some encrypted data to my Android phone. It's limited but useful for storing sensitive text. There is an iPhone app: http://ikeepass.de/ http://ikeepass.de/
- rdl 15y ago
  I use 1password and wifi syncing. I asked them to add WebDAV support to store the bundle, which is how omnifocus does this, which is probably the most cloudiness I will accept for my password file.

sigil 15y ago

> Encrypt with Truecrypt, share with Dropbox. Problem solved. Not so fast. How big is the binary diff when you change a file within a Truecrypt volume? Ie, how much Dropbox bandwidth will you be using, even with a small change? I performed the following experiment. Start with a 250M Truecrypt volume. Mount it. Create a 1M file from /dev/random. Unmount the volume. Now, look at what blocks in the Truecrypt volume file have changed. Dropbox uses a 4M blocksize [1]. seq 0 63 | while read i; do { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.before | md5sum done 2>/dev/null | sort > md5s.before seq 0 63 | while read i; do { dd bs=4M skip=$i count=0; dd bs=4M count=1; } < truecrypt.bin.after | md5sum done 2>/dev/null | sort > md5s.after comm -13 md5s.before md5s.after | wc -l 8 Conclusion: in this case, Dropbox will transfer 32M (8x the normal 4M) because I added a 1M file to my Truecrypt volume. Note: I haven't tried adding bigger files, but suspect the number of blocks changed will go up linearly but steeply with the size of the added file. It's not actually that surprising that TrueCrypt mixes file changes throughout the volume file. Why bring this all up? Because something that does client side block encryption (tarsnap is an example) would only transfer the affected block. 4M, if that's the block size. And you don't have to trust the cloud storage provider at all. EDIT: My pipelines were wrong on the first go, suggesting a much larger number of differing blocks. Sorry about that. [1] http://forums.dropbox.com/topic.php?id=17631 http://forums.dropbox.com/topic.php?id=17631