How To Replace FileVault With EncFS 65
agoston.horvath writes "I've written a HOWTO on replacing Mac OS X's built-in encryption (FileVault) with the well-known FUSE-based EncFS. It worked well for me, and most importantly: it is a lot handier than what Apple has put together. This is especially useful if you are using a backup solution like Time Machine. Includes Whys, Why Nots, and step-by-step instructions."
Question (Score:1)
Re: (Score:2)
RTFA ?
Answer (Score:5, Informative)
I'm tempted to say RTFA but in the interest of saving you and no doubt others a bit of time:
"The biggest mistake Apple did with FileVault is storing the encrypted home directory on a virtual file system. All of FileVault's drawbacks originate from this. The implementation is brilliant, free of bugs, fast and well thought over. But why they decided to have all the trouble with a filesystem in a filesystem remains a mystery."
Essentially, instead of mounting /Users/your_username via FIleVault, Apple decided to add a sparse bundle file to your home directory with all of the contents. The worst impact of this design flaw is it adds a lot of time overhead at log out. If apple instead created a different partition for each user's home directory then there are no real flaws with FileVault.
I can see why Apple did it they way they did - dynamically resizing partitions as the user adds data to their home directory sounds... scary.
Re: (Score:2)
The biggest drawback of that is that Time Machine only works when you are logged out. Also, the "galaxy" interface does not work, but I consider that less of an issue.
The entire point of Time Machine is that it makes hourly incremental backups as you work. Logging out every hour as a penalty for wanting an encrypted home folder is not very seamless.
Re: (Score:1)
Maybe now. Back in about 2003 I used it, and one day when I logged on to my Mac, I got a message telling me that the file was not a valid FileVault file. To make a VERY long story short, ALL attempts (yes, I had AppleCare) to recover the data in that vault failed utterly, so my data record today goes back no further than 2003 for most things (except a few old files that I've found on ancient floppy disks from waaaaaayyyy back when, before the advent of hard drives). Among the thin
Re: (Score:1)
Same here. When FileVault (VileFault, if you like) first came out I ran into the same problem as you. I was able to repair it, log in, and recover some of my data (most resulted in the spinning beachball of death). Trying to convert back to a non-encrypted FS resulted in the machine telling me I needed roughly 12 petabytes of free disk space.
Shame really, it was a good idea, but a very bad execution I think.
Re: (Score:2)
I can see why Apple did it they way they did - dynamically resizing partitions as the user adds data to their home directory sounds... scary.
It's almost like they shouldn't have ripped ZFS out last summer...
Re: (Score:3, Informative)
Maybe you could skim the article next time? Ah... who am I kidding. You just wanted first post, after all.
FileVault:
- Long waiting times at logout
- No shrinking while logged in
- Doesn't work well with Time Vault
- Proprietary
- Weak encryption
+ Well worked out and tested
EncFS:
+Get your space back
+Get rid of the long waiting times at logout
+Back your data up while logged in
+Be safer by using open-source
I can't vouch for the claims.
Re: (Score:3, Interesting)
I like it because I have an office network and need business files to be encrypted, but accessible by other employees. File Vault is a single-user system unless your server is Mac OS X (ours is linux) and the files are stored in a user directory on that server. That opens up the problem that the login for the server then unlocks all the encrypted files.
Using Mac OS X disk utility
Re: (Score:2)
Re: (Score:2)
Your home directory will automatically reclaim space when you log out, that's why it takes so long to do so when you have file vault enabled. But you can reclaim the space on a sparse disk image as well. Unfortunately a quick google search suggests that there is no gui functionality for this.
http://discussions.apple.com/thread.jspa?threadID=1774309 [apple.com]
Re: (Score:2)
You should use Disk Utility to create a large sparsebundle file. Sparsebundles play reasonably well with Time Machine (which is why they exist) -- although as far as I know there's no solution that is both ideal for Time Machine and also doesn't leak file metadata.
FileVault exclusively uses features present in the Disk Images framework (which you can access with hdiutil), except for the trick where it automatically mounts and dismounts the image when you log in and out, using your login password.
Re: (Score:2)
Problems are that the disk images don't expand like File Vault apparently does. Also, doesn't use Time Machine effectively.
These problems both go away if, when creating a new encrypted disk image, you set the format to "Sparse Bundle Disk Image". Sparse bundles are the same disk image format FileVault uses.
It creates a mac OS bundle which contains a series of smaller files called bands which store chunks of the encrypted file system. The file grows in size with the data and is time machine friendly as it can detect the changes in the individual bands and back them up individually.
Re:Question (Score:5, Interesting)
Having read the article, I'd recommend that no one else did. It's written in a preachy patronising tone by someone who is clearly an idiot. For example, he complains about weak encryption because it's 'only AES-128 and you can't change that', except that since 10.5 it's been AES-128 or AES-256, even AES-128 is more than secure enough, and the vulnerability with FileVault comes from how they store the key, not from the encryption used.
He also mentions just as a throw-away 'Don't forget that encfs doesn't support fancy filesystem operations, so don't just throw your whole homedir in there - it won't work.' So, in fact, this can't replace FileVault. Looking at the EncFS web site, I can't see any evidence that it's been audited (even the design, let alone the code). He recommends storing your decryption key in the keychain, which seems very odd; if you don't trust Apple's encryption of your home directory, why would you trust Apple's encryption of your passwords?
He finishes with 'The biggest mistake Apple did with FileVault is storing the encrypted home directory on a virtual file system'. Given that the limitations of EncFS come from the fact that it isn't a proper filesystem, I'd have to disagree there. FileVault does encryption at the block layer, just like most other encrypted filesystems. If you bother to read any of the papers in this area, you will see that there are a number of good reasons for doing this.
Apple did two things wrong with FileVault. They didn't let Time Machine sync mounted File Vault images with other encrypted images and they didn't provide an implementation of something like the TRIM command to let the low-level bits delete space when it was no longer needed.
Re: (Score:1)
For example, he complains about weak encryption because it's 'only AES-128 and you can't change that', except that since 10.5 it's been AES-128 or AES-256, even AES-128 is more than secure enough....
Actually, because of the way that AES-256 and AES-192 were implemented, AES-128 is actually MORE secure than AES-256 (or AES-192 [schneier.com]). IANAC (IANA Cryptologist); but I just finished a project where AES-128 encryption was used, and one of the whitepapers I read said that AES-192 and AES-256 were kind of a kludge, and was actually far more susceptible to a certain class of attacks than AES-128.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
While the FileVault system is proprietary, all of the cryptography is just done through OpenSSL, and what cryptographic routines it uses are documented. (To be fair, they're not documented by Apple, they were reverse-engineered.)
I wouldn't call 128-bit AES "weak encryption", and FileVault supports 256-bit AES. The component that is weak is that you are required to use your login password as the FileVault password. FileVault only uses 1000-round PBKDF to generate a key from your password as it is, and elsewh
not actually solving non-existant problems. (Score:3, Insightful)
+Get your space back
Create a second account, use it to shrink primary account (useful regardless, for many other troubleshooting reasons.)
+Get rid of the long waiting times at logout
And how often do you log out of your Mac? The only time I do that is when I reboot, and according to uptime, I haven't rebooted in more than a week. That was only because of security updates.
+Be safer by using open-source
1)When is the last time you validated the checksum of a package or source? 2)When is the last
Re: (Score:2)
Re: (Score:2)
Even when it has been reviewed, how do you know you have the same source the reviewers had?
Re: (Score:2)
Re: (Score:2)
Well, how frequently do you actually check that?
Mind you, comparing the checksum of a file you downloaded from a server with the one provided by the very same server is completely pointless, you have to compare to the one provided by the reviewers (and you have to trust them as well).
Re: (Score:2)
And how often do you log out of your Mac? The only time I do that is when I reboot, and according to uptime, I haven't rebooted in more than a week. That was only because of security updates.
One mac - 2 days after 21 days, because Parallels/Windows 2008 R2 along with safari ran me into 4GB of swap space it wouldn't release.
Mac two - 90 days. (No Parallels/Windows on this one - needs a reboot with new security patch.
Re: (Score:1)
Create a second account, use it to shrink primary account (useful regardless, for many other troubleshooting reasons.)
... and keep that in sync with your primary account. Seems like a lot of work to me.
And how often do you log out of your Mac?
If you are using time machine to make backups, you have to log out to back you your homedir. This means, you are forced to log out as often as you want to save your work.
Re:Question (Score:5, Insightful)
What are some flaws in FileVault that might make me prefer EncFS?
I've only been thinking of activating FileVault lately and my only other experience has been with ELI in FBSD.
The "flaws" in FileVault (really, just limitations, but whatever), are that they aren't backed up via Time Machine while you're logged in, and space isn't freed up until you log out.
He states that it takes a long time to log out, but that's not true as of Snow Leopard. Sparsebundles recover space very quickly, and you can cancel the logout clean up process without worry.
As for, why would you prefer EncFS? You wouldn't. It actually does work reliably. FTA:
In other words, not only can it not replace FileVault, but it can't even be used for the things a normal Mac user might want to encrypt (Mail folder, iPhoto library, etc.).
Re: (Score:2)
Where I wrote:
As for, why would you prefer EncFS? You wouldn't. It actually does work reliably. FTA:
I meant:
As for, why would you prefer EncFS? You wouldn't. It actually doesn't work reliably. FTA:
Re: (Score:2)
On the Mac, I see five popular utilities for encryption: FileVault/sparsebundle, PGP WDE, TrueCrypt, and EncFS.
PGP WDE of course is good against leakage. Since everything is encrypted even the OS, there is nothing an attacker can figure out about the contents of the drive.
TrueCrypt also good against leakage. One can't tell what filesystem is used inside a TC volume, much less actual contents unless they are able to find details outside the volume (most recently used history, etc.)
FileVault/sparse bundles
[citation needed] (Score:5, Funny)
FTFA:
[citation needed]
Re:[citation needed] (Score:4, Informative)
other than that, I'm all for EncFS. What you lose in terms of security (directory structure and file size are visible) you gain in terms of performance and interoperability with other tools.
Re: (Score:1)
Re: (Score:3, Insightful)
[citation needed]
The six year archive of schneier's blog?
http://www.schneier.com/ [schneier.com]
It often seems that the closed source crypto marketplace in a binary state, either publicly known as snake oil, or not yet publicly known as snake oil. After being burned a zillion times, it seems its all snake oil.
Re: (Score:2)
Are Apple's disk images really so mysterious and horrible as to be called "snake oil"? Reportedly they use AES encryption, and I thought open source projects had even reverse engeered the formats.
Re:[citation needed] (Score:4, Insightful)
No, they're not. Yes, they do, and yes, they have. That won't stop people that don't know anything about encryption from blindly posting Schneier's blog without context to whore for some karma, though.
Re: (Score:2)
For what it's worth, I think there are a lot of things they could do wrong (on purpose or more likely by accident) in their crypto implementation that'd make things a lot easier for someone trying to decrypt it. And these implementation things wouldn't necessarily be occurant to someone reverse enineering the format. Saying that it's AES-128/256 only provides an upper limit for the strength.
Re: (Score:2)
Re: (Score:1)
He simply mentions the above because his article is written for such people, terrorist suspects and people trying to seize control by a coup (but not by other means).
and he thinks his ideas mean anything to macusers? (Score:2)
If you actually read the article while he makes good points to do what he says you have to install macports, and then use the command line.
There is no easy way to setup his system. Sure it has more options but the average user of any OS isn't able to understand all of them. File vault and windows bit locker for all their faults and variations are easy to use encryption. and until all encryption/decryption systems are built into the OS and are easy to implenment then encryption will only be used a handful
Re:and he thinks his ideas mean anything to macuse (Score:2)
I don't think we'll see a universal filesystem encryption scheme until we at least see a universally supported filesystem.
Headline story? (Score:1, Troll)
Why is this a headline story on slashdot. It's a nice little achievement but hardly news. Anyway aren't Apple products suppose to "just work"? How dare this poster find a need for or better fit with something not specifically sanctioned by The Holy Jobs and his minions! ;-)
Plenty happy with FileVault (Score:2, Insightful)
NSA has VileFault (spoonerism, not typo) for brute force dictionary attacks on weak passwords. I don't think NSA would take that route if Apple gave them a back door.
Whoa - Big Fucking Limitation (Score:5, Informative)
FTFA:
That is an absolute deal breaker. Mac OS X (and increasingly third party software) makes extensive use of that metadata in extended attributes. Until it can preserve that same metadata, this solution is a no-go for, oh, 99% of the population. And that last 1% is going to be on thin ice, hoping nothing breaks. Sorry for it sounding a bit like FUD, but this does entail a fair amount of uncertainty and doubt, and that brings some fear into it.
It's a great idea, as FileVault is very limited in its approach, but this is far from a "replacement" for it.
Re: (Score:2)
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 [arg0.net]
Re: (Score:2)
Mac OS X (and increasingly third party software) makes extensive use of that metadata in extended attributes.
Boo Hoo, you won't be able to use Spotlight on your encfs.
Any application that actually *depends on* extended attributes should be shot. File system metadata... even such commonplace metadata as the file name... is inherently fragile, and should only be used as a convenience and depended on as a last resort.
Re: (Score:2)
You mean 99% of the OS X users!
I couldn’t care less.
Re: (Score:2)
That is an absolute deal breaker. Mac OS X (and increasingly third party software) makes extensive use of that metadata in extended attributes.
If you just use it to hide your porn for your boss or your significant other, that's not a real objection.
Re: (Score:2)
It's a great idea, as FileVault is very limited in its approach, but this is far from a "replacement" for it.
So a reasonable thing to do would be to create an EncFS mountpoint and symlink in appropriate directories to your homedir, still on FileVault.
Except, I guess that's just ordinary and usable and doesn't garner a Slashdot headline.
PGP Whole Disk Encryption (Score:2)
Re: (Score:2)
If you don't care what happens when the battery runs out, you can disable SafeSleep (so it's just straight-up suspend to ram) by setting the hibernatemode parameter to 0
see "man pmset" for more info.
For some reason, laptops are set to SafeSleep and desktops are not, which seems backwards to me: desktops don't have a nice battery to gradually drain in the event of power failure, so I'd think they'd want to protect the ram image by writing out the memory at the begining, but laptops do have a conveninent batt
Re: (Score:2)
There's a smarter implementation of this, called "smartsleep". I don't have the time to explain, so google it.
Weak Encryption? (Score:1)
Weak encryption? What was that guy smoking? AES is state-of-the-art, it's security is widely considered sufficient: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security [wikipedia.org]. While there exist attacks on AES 256 which make it a bit less secure, it's still almost as secure as AES 128 which is used in FileVault by default.
Re: (Score:1)
EncFSVault (Score:2)
I wish this project was still alive and well, but it's not been updated since April 2008. :-(
http://code.google.com/p/encfsvault/downloads/list [google.com]
Basically it automates the process of setting up your home dir to use EncFS. If someone could update it and add some features such as painless uninstall. It's pretty easy to disable if you're comfortable with the command line but I wouldn't feel right recommending it.
Fun (Score:1)
On the other side...
Re: (Score:1)
4k sectors (Score:2)
Good idea, so-so choice of technologies (Score:1, Insightful)
The gist of the tip is to create an encrypted container, move your important stuff into that container and then create symlinks from/to the original locations. Be sure to mount/unencrypt the container at boot.
Why ENCFS? Why not a very strong encrypted disk image? Why not Truecrypt? The author doesn't say.
Thanks for feedback (Score:1)
Wow, I was not expecting such a huge amount of comments.
I've updated the article based on this. Most importantly, removed the proprietary part - indeed, that has nothing to do with the howto. This intended to be a howto, not a troll text. I just wanted to add some background to it, for better understanding.