Slashdot Mirror

Note that encfs is perfect for this:
- encrypts using AES-256
- easy to use
- works on linux :-)
- and there's at least one app for Android that is compatible with the encryption protocol
- each file still is stored as a single file so:
      -- no issues with losing all your data at once :-)
      -- replication can still be file by file
- works through Fuse, doesn't need admin rights, kernel drivers and stuff :-)

http://www.arg0.net/encfs
http://en.wikipedia.org/wiki/E...

Amazon Glacier has really changed my backup strategy since this time last year - I now push all my own, generated content (ie: pictures, documents, things I could never get back if I lost everything) up to Glacier using the free Windows client, Fast Glacier. In February I was charged $0.13 by Amazon for storing ~8Gb of data. I tend to push new content up as and when I create it (for example, after I process holiday snaps, or get back from a day out).

Day to day file changes are now handled by Windows 8's File History feature where my changes are pushed to a small NAS (Dlink DNS-320) in my shed (technically off site?) over a Homeplug AV ethernet link. For added security I use the legacy Windows Backup application (still present in Windows 8) to create ~ monthly snapshots of the system which I store on a 320Gb external HDD. This drive is one of two which go back and forth between my parents house each time I got and visit. These disks are encrypted using Microsoft Bitlocker drive encryption.

I should get around to properly encrypting my NAS in the shed, I've been looking at encfs.

The first, and most interesting, is Tahoe LAFS. It does come with a FUSE driver, so it can be mounted like a regular filesystem. It is cloud-based and redundant to a degree you choose yourself. All copies stored are encrypted, so the only person who can read them is you. I'm not sure though if fetching from more nodes than you strictly need to reconstruct your original file actually buys you anything with that system, but I think it does.

You could also use something like a mountable version of Google Drive and then layer fuse-encfs on top of it. That's not quite as secure as encrypting at the block layer. The overall shape of your directory hierarchy is available, even if the individual file names and their contents are obscured. That should probably be good enough for most purposes.

A better solution for encrypting Dropbox content is using BoxCryptor (Win) + EncFS (Linux + Mac). Those are file-by-file-encryption tools which encrypt each file individually. No network overhead, simultaneous access is still possible and you can use features like file versioning or undeletion.

http://www.boxcryptor.com/ [boxcryptor.com]
http://www.arg0.net/encfs [arg0.net]

A better solution for encrypting Dropbox content is using BoxCryptor (Win) + EncFS (Linux + Mac). Those are file-by-file-encryption tools which encrypt each file individually. No network overhead and you can still use features like file versioning or undeletion.

http://www.boxcryptor.com
http://www.arg0.net/encfs

Volume encryption?

Why is it needed? Unless you have a requirement that dictates this, there are more ways for volume encryption to fail.

I am surprised no one has mentioned encfs. You could run it in userspace over whatever precious checksumming system your heart desired.

http://www.arg0.net/encfs

Advantages of pass-thru system vs an encrypted block device

• Size: an empty EncFS filesystem consists of a couple dozen bytes and can grow to any size without needing to be reformatted. With a loopback encrypted filesystem, you allocate a filesystem ahead of time with the size you want. Depending on the filesystem, there may be ways of resizing it later, but that requires user intervention.
• Automated Backups: An EncFS filesystem can be backed-up on a file-by-file basis. A backup program can detect which files have changed, even though it wonâ(TM)t be able to decipher the files. This way backups can be made without needing to mount the encrypted filesystem.
• Layering / Separation of Trust: EncFS can be layered on top of other filesystems in order to add encryption to unencrypted filesystems. This also allows you to store data on filesystems you trust for storage but not for security. For example, EncFS could be used on top of a CD, or a remote NFS filesystem, Samba share, or perhaps even GMail storage using GMailFS.

Disadvantages

• Meta-data: Meta-data remains visible to anyone with access to your encrypted files. This means that Encfs does not encrypt or otherwise hide the following information:
  • The number of files you have encrypted
  • The permissions on the files (readable, writable, executable)
  • The size of each file
  • The approximate size of each filename (to within 16 bytes using AES, or 8 bytes using Blowfish)

The trick is encrypt everything you sync in Dropbox. This can be done transparently. I use encfs and I only sync the encrypted directory to dropbox. I use this solution in my linux, windows and OSX machines. http://www.arg0.net/encfs http://wiki.dropbox.com/TipsAndTricks/IncreasePrivacyAndSafety -- blue

Better to use some file level encryption like e. g. encfs.

Maybe you should, you know, verify that fact before you vent your spleen. EncFS supports xattr, even on OS X. Apparently some people have trouble building the MacPorts version with xattr enabled.

http://www.arg0.net/encfs

Better:

http://www.arg0.net/encfs

More likely that they'll be able to analyze it, but also more likely to be decently efficient. I suppose we'll have to see how it's actually implemented...

Let's hope it's implemented as FUSE, for portability...

If it's actually exposed as a local filesystem, then it should be trivial to encrypt the files using something like encfs.

encfs does the same thing, but also encrypts filenames. It isn't "Enterprise-class" though, so I guess if you are a PHB you probably shouldn't use it.

I use EncFS http://arg0.net/encfs on Linux every day and love it. Even root can't snoop a mounted directory (but could delete the encrypted source directory). How is TrueCrypt better?

under Linux, assuming no malicious programs were running when the OS was under your control, just things like, you're going to be worried about things in /tmp, /var, /home, etc, and your swap partition/file. So, really, the only sane thing to do is encrypt everything-- if you're that worried. But then you have a performance hit, it's less convenient, etc.

Encrypting $HOME is easy and convenient with EncFS and pam_encfs. The main problems with pam_encfs are 1) a readable hash of your encryption key resides in /etc/shadow and 2) each file is encrypted separately, so an attacker can obtain basic size/usage patterns. For more sensitive documents, you should use a separate container, whether a TrueCrypt file, an EncFS directory with a different passphrase, or something else.

Encrypting /tmp and using tmpfs for encrypted swap is easy. /var -- most of what queues in /var passes over the network, so unless you're using IPsec extensively or have a local print queue (OK, that's a lot of people), I wouldn't worry too much about /var.

The performance hit on modern hardware is negligible, at least for normal "desktop" operations.

Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.

:j

Right; This is also what firefox does (when you turn it on) with the "Master Password" for remembering website login passwords.

That's a case that's potentially justified by large numbers of passwords (I have dozens). I also use gaim with about 20 accounts, so it would be a good idea there, too. Most users, however, will probably only have one or two, so trading two passphrases for one may seem like too much hassle for the added security (for some).

I compromise by using encfs to encrypt my ~/.gaim/ directory (among others), but that has its own limitations. Other users (including root) can't read the files, but any app running as my user can, while the fs is mounted.

Check out FuseFS, for example (see why it's cool). Or encfs (see O'Reilly article).

Linux is starting to go beyond emulating the Unixes of yore, to create a whole new world of computing.