Using FileVault on a Mac with existing data

It depends on how serious your potential adversary is. If they're just using normal data recovery tools, they won't be able to get at anything without breaking the encryption first. But because of the way SSDs write data, if they're really serious about it, an adversary could disassemble the SSD, bypass its flash translation layer, and get access to blocks that've been "overwritten" but not physically reused yet.

SSDs actually have more capacity than they expose to the outside world (i.e. the computer), and when you "overwrite" a block, it doesn't actually overwrite the physical storage, it puts the new data in a different physical location, updates its translation table so the outside world sees the new contents instead of the old, and adds the old physical block to a reserve that'll later get reused for some other logical block. See this AnandTech review for way more details (warning: the relevant bits are scattered through a very long review).

Because of this (especially the fact that the flash controller hides what it's doing), making sure that all old data is overwritten is really really hard. Researchers at the Non-Volatile Systems Lab at UCSD have tested various ways of sanitizing SSDs by "erasing" the drive, then disassembling it to bypass the controller, and checking for remnant data (summary, full paper). They're considering the problem of erasure without replacing the data with an encrypted version, but the basic problem is the same either way. And their results weren't pretty:

Our results lead to three conclusions: First, built-in commands [ATA secure erase] are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.

If you're worried about someone going to that much trouble to get your data, there are a couple of options that might work:

• Convert to FileVault, then create & delete a bunch of large files to force enough block reuse to fully drain all blocks containing old data out of the reserve. How much will this take? According to the NVSL's results, creating & deleting files equal to the capacity of the SSD should do it (the conversion to FileVault essentially overwrites 1x the drive capacity, so you need to bump this up to 2x).

• Copy all of the data off (preferably to an encrypted drive, so we don't expand the problem), run an ATA secure erase on the SSD (essentially, tell its controller to overwrite all physical blocks), hope that the controller actually does this right (not all will), then encrypt and restore.

And one option that will work:

• Replace the SSD, encrypt the replacement before copying data from your old SSD, then physically destroy the old SSD. And BTW I want complete physical destruction, not just breaking the controller board and leaving the storage chips intact; see this analysis from the NVSL people on how fine you need to grind it.

I realize none of these are particularly good options, but it's too late for the best option of all:

• Never ever store sensitive data on an SSD in unencrypted form.

FileVault was designed to be enabled at any time so you will have no problems encrypting your data after the fact.