[ Stupid LiveJournal, email-posting is broken again, so this will probably be a dup once their mail server coughs up the now-8-hours-old other version... ]

Dear Lazyweb,

FileVault: good idea, or performance killer?

To use it effectively, must I arrange for all my music, video, and XCode build directories to be on another partition? Because that sounds like a pain in the butt.

Tags: , , ,

79 Responses:

  1. unixoid says:

    I see three potential problems for current customers and advantage for apple hardware department

    1) Need for faster disk (striped/raid, etc)
    2) Need for more CPU power or some dedicated hardware encryption solution
    3) Need for more and faster RAM.

    Looks to me like very good marketing strategy.

    • taffer says:

      I used it on a 1GHz titanium PowerBook and didn't notice much of a hit; then again, I didn't have music or photos, etc. on the machine, it was for work. It had a "moderate" amount of files on it in $HOME, but they didn't tend to change that often.

      I don't use it on my iBook because I don't want to pull my iPhoto library out into a different location.

  2. tkil says:

    I think that it is both a good idea and it's a performance killer.

    Here's at least one report that FV is enough to make some tasks difficult:

    Two further thoughts, both of which you most likely already have thought:

    1. Ideally you'd put the sensitive stuff (mail, contacts, etc) in one area that would be encrypted, while bandwidth-intensive non-sensitive stuff (the three you mention, basically) would go unencrypted. I don't know how possible that is, on OSX or any other platform.

    2. For a machine that is not moved often, nor out of your control physically, the convenience/security tradeoff probably leans towards convenience and speed at the cost of security. If you had a laptop that you took everywhere, the risk of lossage would go up, and the blaance might go the other way. *shrug*

    Sorry I don't have better links/suggestions.

  3. herbie says:

    I've heard many reports that filevault reduces reliability inasmuch as it's not uncommon for a small error corrupts your entire home directory. Common wisdomw seems to say that files you want to keep safe might be better off in an encrypted DMG, but they don't auto-resize nicely. (Essentially the problem is that with filevault, your entire home dir is one large encrypted file, such that an error in one place can corrupt the whole thing.)

    • jwz says:

      It sounds like FileVault is implemented as just a "sparse" encrypted DMG, and I think those resize. At least, they do resize up instead of being of a fixed size at creation-time.

      • FileVault volumes are indeed sparse disk images. If it gets too bloated then it offers you the option of compacting it when you log out.

      • herbie says:

        Well, that's useful - but my point is that it's better to explicitly create the DMGs and use them as needed. In fact, create many of them and use them for various things - that way the effects of data corruption can't be as widespread.

    • daikon says:

      Heh. That sounds like the old DoubleSpace problem in the pre win95 days. the smallest error would fuck up your shit.

  4. As the Reiser4 filesystem has (kinda) proven, today's computers actually get a performance boost out of having a compressed filesystem. The whole data pipeline to/from disk is so throttled by the hardware that there is a ton of unutilized CPU bandwidth that can handle the compression and encryption fast enough to make it an actual performance win in some cases.

    Personally, I've been using FileVault for over a year and have never had a single problem or even a hiccough.

    • jwz says:

      Do you use iMovie? There seem to be many reports of any video work being too much for FV to handle.

      • evan says:

        This is exactly what happened to me in my brief mac flirtations -- had to make a separate, non-encrypted partition to hold my movie. Otherwise imovie couldn't copy movies off of the dv camera.

        And then when I backed it up I forgot the weird /movie directory and lost my movie forever. :(

  5. allartburns says:

    I didn't notice any real performance hit for "typical" usage: email, web browsing, writing docs, etc.

    HOWEVER, if you use any sort of backup software, every change causes the entire FV file to get backed up. For me and my stupid 40G of scanned slides and negatives, that got to be a PITA.

    Maybe if you put all your big, binary data outside of your home directory it's not as big of a deal?

    • jwz says:

      Yeah, that's the obvious solution, but it definitely falls into the "pain in the butt" category. I kinda like having everything under ~/ instead of scattered to the winds via symlinks... And then suddenly my incentive is "don't encrypt it because it's big" instead of "don't encrypt it because it's not private", which is lame.

  6. duskwuff says:

    VileFault is a nice idea, but extremely hazardous. One inopportune power failure can hose your home directory. Having lost several months of work to it once, I would strongly not recommend it for desktop use.

    That being said: Music is probably fine in an encrypted FS; video, however, is definitely not. XCode builds are generally constrained by the CPU, not the disk, so it probably won't be an big issue there (but a benchmark would be well-advised if you're concerned).

    • By music, do you mean MP3s/AACs in iTunes, or multitrack audio editing in Logic/ProTools?

    • legolas says:

      XCode builds are generally constrained by the CPU, not the disk, so it probably won't be an big issue there

      Except that de/encrypting takes CPU, and so reading the source files will take CPU, as will writing the object files generated if they are put anywhere near the source files. And then, come link time, reading all the object files will take CPU, and writing the linked file too. And depending on where your temp files are put, those too. Seems like quite a bit of opportunity to make the CPU a little hotter ;-)

      I'm not sure how XCode sets up it's projects, or allows you to set up your projects, however, so some of the above may not apply?

  7. ioerror says:

    FileValut it a pile of shit. You and computers already have trouble. Don't tempt fate Jamie!

    The encryption is crap[0]. It's like someone just slapped it on and didn't even give it a second thought. The thing is just buggy as shit and until 10.3, it was entirely broken in every single way possible for a file system.

    [0] AES is fine. It's not AES that's the problem. It's everyway that AES is used by apple. The keys are SWAPPED to the disk unhashed! Grep your swap file for your passwords. What the fuck was apple thinking?

    • herbie says:

      Wow, that's... that's phenomenal. Although, (pardon my ignorance), in a situation where you have unhashed keys in memory (which at some point must happen), how can you ensure that the OS won't swap it to disk?

      • jonabbey says:

        Lots of operating systems (Linux, I know) allow pages to be 'pinned' into RAM, so that they are never paged out.

        I believe this requires root privs (or the equivalent capability bit set) on Linux, but for an OS-level crypto feature, that's no hardship.

        • eqe says:

          mlock used to require root on Linux, but nowadays (2.6.x and IIRC even late 2.4.x) there's a ulimit setting controlling how many pages normal users are allowed to lock.

          However, pinning pages doesn't do jack if the OS decides it's really going to write out. In particular, Linux swsusp "suspend to disk" will write out every page including any mlocked ones. Pretty much any suspend-to-disk system has to do something along those lines...

          • herbie says:

            'course, Suspend 2 supports encrypted suspend...

          • legolas says:

            Simply respond to the systems suspend announcement by clearing the password in memory. After coming out of ssupend, most users won't be too surprised they'll have to retype it, I think.

            • eqe says:

              Indeed, that would actually work just fine even for several of the cases where people use mlock in the absence of suspend-to-disk. Unfortunately, there's no way in the standard UNIX paradigm to communicate such events to the user. The NetBSD Scheduler Activations (SA) work solves a similar problem, but isn't quite right for this purpose (and is quite esoteric and of course, completely unportable).

              Basically, several things that it once made sense (at least arguably) to completely hide from userspace (disk I/O concurrency, paging decisions, and scheduling decisions) really should be exposed to application logic as apps become more complex and the decisions being made become more sophisticated.

      • transgress says:

        mlock() and mlockall() are both in IEEE Std 1003.1:2001.

        For windows, you can use VirtualLock()

      • ioerror says:

        It really is amazing. It's great when a company says: "Unbreakable!" And then they make some massive mistake. Its like they didn't even look at the other open source disk crypto stuff and see what mistakes those projects made!

        Ok anyway. First off, simple solution (imperfect): Require encrypted swap with randomly generated keys at boot time if there are any encrypted file system keys in memory. The best way to clean a disk is to never let anything important touch it in an unencrypted fashion. Seemingly random data on the platter only. That allows for flawed crypto passphrases to be swapped until the cows come home and it's at least a step above what they had in 10.3. As far as I understand it, that's what they did in 10.4.

        Secondly, don't use a straight password as the key to the file system. Hash the users key through n iterations of something first. Salt it. Precomputing a dictionary for the first known blocks of a drive isn't impossible. The known plaintext is pretty limited and easily predicted.

        Regarding not swapping to disk, locking memory pages is the solution. Just as a reference, gpg(1) says: Locking memory pages prevents the operating system from writing memory pages (which may contain passphrases or other sensitive material) to disk. As such gnupg (in userspace) solves the key to disk problem by using memory locking, apple should be able to do this in the kernel. I think they'd want to do this with mlock(), I'm not entirely sure about Mac OS X specific programming. If the OS can't do this, it's broken.

        A better solution is possible but even jwz doesn't care about this shit other than knowing that it's poorly implemented and isn't worth trusting data with.

    • transgress says:

      I haven't really had more forensics experience with FileVault, there seems to be a direct correlation between OSX users and not commiting crimes, I'd imagine its similar to pirate and global warming. None the less, MSs EFS often fails because the user fails to remove critical certificates from the system, then their drive gets pulled and the entire glass house falls.

      How are such things implemented in filevault? If a system user such as root changes the users password, does this action cascade and change the password for their encryption as well? So on and so forth.

    • inoshiro says:

      Look closely, and observe the "[ ] Use secure virtual memory" option. That solves you problem :)

      This was a new feature they added in Tiger to fix up this rather obvious security hole.

      • ioerror says:

        Yeah I've seen it.

        How does that make FileFault more secure?

        If anything, I would worry about a bandaid solution to get a shipping product out the door.

        And it doesn't seem like a very obvious security hole to me. It took Apple forever to fix it and if they had done their homework, it wouldn't have been an issue in the first place.

        • transgress says:

          the 'secure vm' option encrypts your swap file, supposedly making it a moot point. What I'd imagine though, is that the encryption is implemented poorly and you can probably find the key to that somewhere in memory.

          I more or less agree with you here Jacob, but I'd go more broad and say 'any encryption that you can use with the same credentials that you use to login to the system is most likely not secure, especially so if you do not have the options of exporting keys or certificates off of the hard disk'

          • legolas says:

            Euhm, encrypt it or obfuscate it? Unless it somehow uses the users password to encrypt the vm, it's obfuscation really.

            And if it is encrypted using the users pwd, does that mean no virtual memory is available when no-one is logged in, and all virtual memory becomes inaccessible when the user logs out?

            I guess not, so I'm guessing the key is indeed somewhere in the OS.

    • packetslave says:

      You can avoid this by enabling the option "Use Secure Virtual Memory" in the Security preference pane. I'd imagine there's quite a bit more being swapped out in cleartext than just your FileVault password. This option will encrypt your swap before it's written to disk. A quick Google seems to show mixed opinions as to whether it affects performance or not.

      • ioerror says:

        You can't avoid pile of crap software by tacking on more crappy software to fix its flaws.

        It does affect performance. Swap is already slow.

        And yeah, it does swap out tons of crap other than your login password. They swap everything you would care about to disk.

        • transgress says:

          And yeah, it does swap out tons of crap other than your login password. They swap everything you would care about to disk.

          Sadly, most people writing this type of software do not think about issues like this, at least not in their initial releases. It wouldn't surprised me to find out that you can find the keys in plaintext in memory, or in core dumps and such given the right circumstances. In a way, I can see how someone could forget these types of things because swaping and such is something thats transparent to the application developer, and thus is easily forgotten.

          That said, if you're writing this type of application these are things you are supposed to think about, and thus the reason why i can only 'kinda' understand it instead of totally empathize with it. If you look at the history of many of these types of software, you will find similar bugs all over early editions of the software.

          Finally, in most unix environments, while swap is strongly suggested, its not mandatory, I'd wonder if you tell OSX 'no swap for me thanks' and avoid the issues all together (or exchange them for other issues rather). Even then however, presuming the box has no adverse effects from not having swap, I'd bet you can find the same information unencrypted in memory, and as pretty much every incident response/forensics policy requires a dump of memory in a live acquisition, the gig is probably up there as well.

          Personally, I wrote a small application to use one-time pads for myself, and I keep a usb key full of the keys. I use PNRG to get the random bytes, which is a weakness in my implementation which means its possibly breakable to uber cryptanalysts, but i cant recall a time where I was really concerned that people at the nsa were analyzing my encrypted data, so the PRNG works fine for me, I know the implementation is not backdoored, because its only for me, the key management isn't an issue, and I know no one I'll most likely ever meet will be able to crack it,

          • cananian says:

            Nice. "I don't trust Apple to write a non-broken encrypted file system, so I'll use my own instead which I *know* is broken!"

            I don't know what PRNG you're using, but most of them are crap. It's not a "one time pad" if you generate the bits with a PRNG, you know. It's just a weak XOR system. I bet you keep the same seed and used a fixed-size pad, as well?

            • transgress says:

              The PRNG varies from box to box. Fact is depending on the underlying data, even an XOR is hard to crack, presuming a unique key and data that isn't easily recognized, have you ever tried to brute force some XOR knowing the end result was ascii printable? You end up with a lot of results, many of which may also be valid. This is also the strength of OTPs. Of course your average PRNG isn't strong enough for 'truly' secure OTPs, but for anything less than a spanish inquisition, it will be strong enough. That combined with the obscurity of it, provides a safe means for me email various data sets without having to use PKI.

              If you really feel this way, I would be happy to post an example to you and let you show me how weak it really is.

              • cananian says:

                Just because you don't know how to do it, doesn't make it hard.

                Breaking XOR-encrypted data is typically problem 1 of problem set 1 of cryptography class here at MIT.

                And don't keep callling your system a "one time pad". That just makes it clear that you don't know what you're talking about.

                • transgress says:

                  So what you're saying is that you're willing to put your money where your mouth is and crack an example?

                  • cananian says:

                    Sure, if you're willing to pay for my time.

                  • transgress says:

                    so what you're saying is 'no, i dont have enough confidence in my supposed abilities, so i will suggest you do something obviously no one will do, so that i dont have to be proved wrong'.

                    And yes, I know what a one-time pad is.

                  • cananian says:

                    What I'm saying is that my time is too valuable to waste further with a fool.

                    Last chance for your edification (why do I have this savior complex?):
                    Wikipedia, bullet point 2. I'll note that this is google's first result for "one time pad". You'd really be better off reading Schneier.

                    You're cute, but I'm bored now.

                  • transgress says:

                    You paid far too much for your education. I am familar with the flaws of prng's, I even mentioned it in my original comment. What I am saying is that you're full of shit and couldn't break the code, prng and all.

                    Your time isn't too valueable, your skills are lacking, and thats the bottom line, no matter how your sugar coat it.

                  • transgress says:

                    Okay, how does this sound, if you can crack the following in say, a month (30 days), I'll send you $500, and if you can't you send me $250. If you crack it, I'll conceed your point and send you the money. I even went so far as to not ensure that each column had a fixed length, giving you an obvious advantage.

                    11324 9988 23721 9007 4752 8194 219 5149 5713 1393 14036 17827 13592 26768 5466 16236 2782 9415 15376 20555 3397 12093 29164 12565 11469 7981 27338 21697 696 3629 6701 12620 2561 138 6288 25986 6755 24627 9272 13892 13183 7537 9513 11243 2339 19410 21474 11753 9328 1020 10656 20172 17666 1771 3762 2758 16914 10878 24738 17548 7221 267
                    18 22905 2672 8309 17443 17580 1832 5954 227 16447 816 28527 13072 6287 7619 3405 5933 1955

                  • transgress says:

                    It should read:

                    11324 9988 23721 9007
                    4752 8194 219 5149
                    5713 1393 14036 17827
                    13592 26768 5466 16236
                    2782 9415 15376 20555
                    3397 12093 29164 12565
                    11469 7981 27338 21697
                    696 3629 6701 12620
                    2561 138 6288 25986
                    6755 24627 9272 13892
                    13183 7537 9513 11243
                    2339 19410 21474 11753
                    9328 1020 10656 20172
                    17666 1771 3762 2758
                    16914 10878 24738 17548
                    7221 26718 22905 2672
                    8309 17443 17580 1832
                    5954 227 16447 816
                    28527 13072 6287 7619
                    3405 5933 1955

                  • cananian says:

                    Snake Oil, warning signs #3, #4, #6, #7, #9. See also, the fallacy of cracking contests.

                    Once again I am, against my better judgement, trying to educate you instead of being wildly insulted that you think a month of my time is worth $500. Email me your complete "super sekure" hard drive and put up some real money and we'll talk.

                    I don't expect my pedagogical inclination to last. But you're such a great troll...

                  • cananian says:

                    Doh. I meant, "mail me", of course. Last thing I need is a gigabyte email of encrypted kiddie porn.

                    Your 15th group is off by one. You might want to check it.

                  • transgress says:

                    Am I supposed to just guess your mailing address?

                    And no, my 15th group is not off by one, good try @ disinformation though ;]

                  • cananian says:

                    Oh, sorry, I meant the 16th.

                  • transgress says:

                    again, incorrect. Turn off your overly expensive RDF, you won't crack this one, your dataset simply isn't large enough. Thinking that you're spinning my wheels by stating one of the groups is off is silly and underscores your inability to crack the code. There is no known header, nor known content, the best you have is the variations of length, this is the difference between theory and application. It's too bad that in your almost 15 years of education that you still haven't picked that one up.

                    If you want me to mail you a drive, I will.

                  • cananian says:

                    I'm sure the 23rd group has the 6th bit flipped. Could you recheck it?

                  • transgress says:

                    Snake Oil, warning signs #3, #4, #6, #7, #9. See also, the fallacy of cracking contests.

                    No, see you are distributing the theory that using a prng is ultimately a failure period, whereas my point is that yes you are correct given the right circumstances, however given just that data previously posted, your timeline and dataset is not long/large enough for the prng to be a weakness.

                    Once again I am, against my better judgement, trying to educate you instead of being wildly insulted that you think a month of my time is worth $500.

                    Well you are a php developer afterall ;].

                  • transgress says:

                    what do you classify as 'real money'? I make decent money and can afford to lose an expensive bet, however I wonder if, as a student, you can?

                    If you're willing to put some 'real money' behind your mouth, then I will mine, and I'll send you a drive.

                  • master_meio says:

                    Your icon- Fucking Christ, you look like a dick.

                  • cananian says:

                    I'd have to offend on substance but not on style. Thanks for letting me know I've got the bases covered. =)

    • aszegedi says:

      System Preferences -> Security -> Use secure virtual memory

      will cause your swapfiles to be encrypted as well, voiding your argument.

    • netik says:

      When I worked in Apple Security (at Apple) we did a full review of FileVault and found exactly the problem you describe. We then filed bugs with R&D which were ignored because of an impending release date for 10.3. Our solution for using FileVault at the time was to use Hardware smart cards by CryptoCard, which moved the keys-in-memory problem to be a keys-in-secure-hardware issue.

      Also, I don't know this has been mentioned but FileVault supports key escrow, which is a whole other nasty issue. We actually deployed an escrowed key out to every laptop we could at Apple so that we could get into systems in the event we had to do forensics, at the request of HR. Sigh.

      • srattus says:

        I imagine that it would be a bit of a selling point for enterprise IS types if this process was in a whitepaper somewhere.

        I've been fairly astonished at apples lack of ability to market to anyone other than people who like pretty things and fbsd users.

      • taffer says:

        CRYPTOCard has great hardware keys (compared to, say, RSA), but you might want to audit their software, development process, documentation, and source control. They have a remarkably high level of employee churn for such a small company.

        I'd say more, but then they'd try to kill me; I worked there for a while.

  8. rantzilla says:

    I recommend not using FileVault. While it is much stabler than it was, it still has issues.

    I recently lost my FileVaulted home directory due to disk crash. Granted, I was not backing up like I should have been. On the other hand, DiskWarrior was unable to help me because it cannot yet deal with sparse disk images, which is what FileVault uses. Read the man page for hdiutil for some extra information on sparse images.

    There's also the performance issues. Longer to log in, longer to log out. Arguably slower read/write times due to the encryption.

    Again, if your sparse disk image gets corrupted or the disk dies, you are pretty much fucked.

    Having stuff on other partitions, which I have also done, is somewhat of a pain. iTunes and Xcode both have means of keeping your music or build directories elsewhere. You'll also want to have your download locations not in your home directory if you use FileVault.

    If you have stuff that you need encrypted, I recommend making your own pre-sized read/write encrypted disk image (or a sparse image) and using that to protect your valuables.

    And back up your system more often than you think is reasonable, especially if you use FileVault. After my disk crash, I not only don't use FileFault anymore, but I clone my whole system to a firewire drive partition every day.

  9. transgress says:

    While your typical forensics tools like Encase and FTK don't come out of the box with the ability to break FileVault like they do EFS, I'd imagine FileVault typically fails in the same ways that EFS does. Improper key/certificate management typically makes it worthless.

    In 95% or more of forensics cases that I've worked on the user fails to remove private keys or passwords from the systems disk, and thus the encryption is essentially pointless. That said, the problem with EFS is that the system creates a system recovery certificate that Encase and co use to decrypt the data. In my little use of FileVault, I haven't seen any options to move keys off disk or similar, although I haven't really looked either.

    That said, before I implemented it on something I thought needed to be encrypted I would verify that Apple hasn't included any 'oh shit' recovery functionality like MS did and move such things off the disk to a safer location like a thumb drive or similar, and see how the private key/certificate is stored exactly, and how easily it could be attacked, i.e. does a super user changing your password also change the password for your encrypted drive, etc.

    If all else fails, you could just try this link

  10. sapp3r says:

    I ran FV for two or more years, but no longer do so.

    The primary reason for this were numerous data losses that occured with some regularity. (Once every three or four months or so.) All but the last of these were merely nuissance level: I'd generally lose the preference files for applications that were open at the time of an event that caused unexpected shutdowns. (The app crashed, the system went into suspend mode, or lost power, etc.) I always ended up redoing the prefs by hand, because restoring my homedir would have reverted the state of my data, which wouldh have been worse. (I'd also dumbly had this idea that FV made backups more convenient because then all you had to do was backup the sparseimage file. Nice theorry.)

    The last data loss -- the straw that broke the camels back -- involved corruption to the volume, on a fairly large scale. There is NO utility that recover this. Period. If you don't back up religiously, and often enough, then you'd be well and truly fucked. I'll spare you the rest of that sob story.

    Outside data loss, there's the issue of performance. I did in fact move my media files outside my home directory. It wasn't so much that iTunes was slow or something, but of course, backup times, etc.

    I'd say that if you're going to use FV, take the following actions:

    1.) move media files (or other large collections of data, etc.) somewhere outside your home directory. i used soft links to enable this, because changing all of the preference files would have been a pain in the ass.

    2) BACKUPS. you can logout and backup the sparseimage file itself, which is damned convenient. if you need to restore some but not all of your homedir, you would have to put the image in an alternate location, open it, and grab what you need, transferring it manually. if you don't backup the sparseimage file, then you'll need to have your backups done while it's mounted and open, etc.

    3.) make regular online copies of preferences for safari, mail, and itunes. you won't regret having set that up.

    hope this helps.

  11. markuppedant says:

    I've never noticed a performance slowdown subjectively with anything but the firewire video. I kinda suspect the filesystem buffering should get it out of the way, pretty much. I do a lot of SW dev (NetBeans not XCode, but whatever) & rip & play a lot of music.

  12. grahams says:

    I was running FileVault. It just creates and encrypted disk image to store your home directory which it dynamically grows as needed. When you log off, it asks you if you want to "shrink to fit" the disk image (in the case you added then removed files and the image was unnecesarily big.

    I said yes to this harvesting once, but I was about to go to bed. While it was doing it's thing, I decided that I'd better mute the audio on my laptop before going to bed.. I pressed the mute combo on my keyboard, and this 'reaping' process stopped instantly.. I figured this was coincidence and went to bed.

    I woke up in the morning and logged in and everything was acting wonky.. Turns out that the process died and left my homedir in some half-fucked state. I had to blow away that user account and restore from backup (which I thankfully keep every two weeks) to fix things.

    I highly recommend against FileVault.

  13. kchrist says:

    I've been using FileVault since it was introduced, on two different laptops, and I haven't had a single problem.

    As far as performance goes, the first laptop was a 600MHz iBook and if it could handle it, anything can. I did keep MP3s in /Users/Shared rather than in my home directory to keep the size of the encrypted data down, but I had a couple gigs even without them.

    Anything can fail, of course -- you of all people should know that all software sucks -- but you are keeping backups, right? Any sparse image corruption should amount to little more than an inconvenience, in the unlikely event that it occurs at all. As a mobile user, knowing I have good backups at home make the slim possibility of data loss an acceptable trade-off for the security I get out of it.

  14. aszegedi says:

    I use FileVault on a 2.1 GHz iMac G5 since last October, and had zero problems with it ever since. The sparse file increases its length as it needs to, when I (rarely - mostly when updating the OS) log out, it compacts it. AES is a very fast symmetric cipher and I can feel no performance degradation whatsoever. I'm building code for a quite large distributed enterprise system on this machine inside of the home directory regularly, so it's being excersised quite a lot. As for backup having to back up the whole sparse file, here's what I do: I don't back it up. Instead, I have an identical encrypted sparse file on the backup drive, mount it prior to running my backup script, and let rdiff-backup work its incremental update thing inside of it. I myself am thinking about moving out my iTunes folder into an unencrypted directory and symlinking it sometimes, but I always realize it's just the pedantic in me, and that I don't actually have any problem that this is supposed to solve...

  15. wmertens says:

    I'm a sysadmin, some of our users work on powerbooks.

    We enforce using FileVault, since we need to have company data be secure. Regarding the comments about passwords in swap, well, it's better than no encryption.

    So I have datapoints from about 70 users over a year's time. Basically, it's rather stable, but don't consider using it without having backups of the data stored in it. Don't backup the sparseimage, it's pointless except for quick recovery situations.

    For backups, I wrote a GUI wrapper that runs rsync over ssh every so often while the user is logged in. You're welcome to it if you want it.

    My points:
    - Your access speed becomes about 2MB/s. Mostly CPU bound. This is not a problem for daily things. I even do my compiles in my homedir.

    - FileVault is encrypted using a key that is stored with it. That key in turn is encrypted using your password and an optional master certificate. Either can unlock it.

    - Please do enable a master password as well. This is used to unlock the keychain in /Library/Keychains/FilevaultMaster.keychain, which contains the private certificate. You can safely remove this from your system and store it elsewhere, you only need this in case you want to recover from a forgotten or corrupted password (yes, this has happened in 10.3).

    - I keep my music and movies in a non-encrypted directory, /local in my case. Reasons are copy speed and FileVault size. If FileVault becomes big, it was very slow to compact in 10.3. 10.4 seems to have improved there.

    - When you log in, loginwindow will read your NetInfo entry and mount the filevault that it points to using your login password as the key, on /Users/jwz. To do that, it moves your homedir to /Users/.jwz and creates a new /Users/jwz, so that you can still access the sparseimage while it's active.

    - Read the manpage for hdiutil, it's what makes this work.

    - I prefer compacting by logging in on my administrator account and running hdiutil compact from there. That has a progress bar unlike the logout thing.

    Bottom line, if your system ever gets stolen, you'll be happy you had it active. Also enable the boot password and screen saver password.


  16. fantasygoat says:

    The paranoid people at work use GPG.

    The Mac specific one:

    That way it the files stay encrypted on the backups as well, whereas FileVault gets backed up unencrypted.

    • tooluser says:

      . . . [name deleted] at PGP is of the opinion that PGP's Whole Disk does this much better. And even though I work for them, I don't use it*, so really, I'm just like any other schmuck mentioning a product he doesn't use. But no one else had mentioned it; wanted to get it out there.

      I definitely avoid Apple's FV, though. The swap problem mentioned earlier has been IIRC solved a while back, but it's that character of error that makes me assume it's like most other things built-in: decent for mom's Quicken data, but probably not satisfactory to someone who inherently crave a more complicated solution.

      (* because as an employee I'm kinda required to run pre-release versions of it, and 'pre-release' and 'your entire hard drive' are not my two favorite phrases to see in one sentence.)

  17. xah_lee says:

    i turned on FileVault on my 800 Ghz G4 iBook for a year about 2003. I had absolutely no problem whatsoever. But, there is a very noticable speed penalty on this slow machine. I think the penality is more in cpu, than hard disk access. I think i had my mp3s outside of my home dir though. So, can't say how they effect mp3 playing.

    it is because of the speed slow down, i turned it off eventually.

    i thought maybe i should turn it on again on my new desktop machine... but didn't bother. I didn't bother because i thought i shouldn't be that paranoid to want to have everything encrypted. Secondly, if i want encryption, it had to something NSA couldn't break. Either that or no encryption at all. I wondered, just how safe is a file encryption system produced by a mass marketed commercial American corporation for the average consumers.

    so, currently i just have a directory that's encrypted. I'd trust far better with GPG, but due to convience reasons i'm currently using Apple's hdid.


  18. freiheit says:

    1) tried it myself back in 10.3. Lost my homedir. Basically ask yourself this: ever had a single unclean shutdown for any reason? How much would you curse the computer if your entire home directory was lost when it happened?

    2) I think we use this at work. It's perfect for the situation at work: there are laptops on-campus that if they're lost or stolen, the media must be notified and it costs all sorts of money to deal with. Unless you're using encryption. Then nobody needs to know. I think with Windows they went with a commercial product that doesn't come with the OS.

    In other words: for some organizations, turning on FileVault means saving money. Up to $250K of money. And avoiding a public relations nightmare.

    Do you have SB 1386 section 2, paragraph e type material on an easily snatched computer? That'd be name plus any of SSN, CA ID card/driver's license number, credit card number, other bank account numbers...

  19. marapfhile says:

    I don't know if this is relevant to you, but the one time I tried using filevault, I found it made my home directory completely inaccessible when ssh'ing into the box--it showed a couple dotfiles and nothing else. At least with encrypted DMGs, there is presumably some way to mount them from the command-line (though I don't know it myself).

    • wmertens says:

      Read my post above, search for hdiutil. Either you were logged out and for some reason your .username directory wasn't moved back, or you missed the username.sparseimage file.

      you can mount it from the commandline using

      hdiutil mount -stdinpass username.sparseimage

  20. crucially says:

    terribly bad idea if you ever crash while growing the virtual partition