Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

An Introduction to File Encryption in Mac OS X

Last year, in between writing Take Control books and Macworld articles, I managed to squeeze in another little project - writing the 900-page "Mac Security Bible," published in January 2010 by Wiley. Although Rich Mogull is the real staff expert when it comes to Mac security, I've also written a good deal on the subject, including Take Control titles dealing with backups, spam, and passwords. This new book is a compendium of everything a typical (or even advanced) Mac user might want to know on a wide range of security topics.

This article is an excerpt from Chapter 13, "Encrypting and Securely Deleting Files," reprinted with the kind permission of Wiley. File encryption is of course just one tiny piece of the security puzzle, but it's worth knowing about if you keep confidential data on your Mac, especially if the computer is ever out of your physical control - which would include being lost or stolen.

Think about it this way: Would it bother you or any of your friends or family if the entire contents of your Address Book were made public? Would you be disturbed to know that a stranger could see years' worth of your family photos, read all your email, and discover every Web site you've visited in the past month? Even the least secretive of us would probably agree that all this sounds pretty creepy, and that we have good reasons to keep private information private.

The way to keep your data safe while it's sitting on your hard disk is to encrypt it - to scramble it in such a way that it looks like garbage to anyone without your password or key. Encryption comes in many forms, some of which are almost trivially easy to use, and others that require extra thought and effort. The chapter from which this article is excerpted explores a variety of different approaches to encrypting some or all of your files.

Encryption Algorithms -- An encryption algorithm, also known as a cipher, is a particular method for encrypting data - a sort of mathematical formula that takes the input (sometimes called cleartext), processes it using a secret piece of information (a key), and produces encrypted output (sometimes called ciphertext). Over the centuries, countless thousands of encryption algorithms have been developed, ranging from the extremely simple to the breathtakingly elaborate. In the modern computing world, you're likely to run into at least a half-dozen common ciphers considered especially well-suited for encrypting and decrypting data on your Mac.

Two factors influence how secure (resistant to being broken) an encryption algorithm is. First is the design of the algorithm itself. Some have weaknesses or design flaws that could enable an attacker to decrypt data even without knowing the key. The other factor is the complexity of the key. If you use the world's most complex and powerful cipher but give it a simple key, such as the word "cat," it becomes quite easy for someone to figure out how to decrypt your data. The best results come from combining solid, reliable algorithms with long, random keys.

I could spend many pages simply listing encryption algorithms and their variants, but I want to briefly acquaint you with just a few especially common ones:

  • AES. The Advanced Encryption Standard is one of the world's most commonly used ciphers and one accepted by the U.S. government for protecting secret data. AES can use 128-, 192-, or 256-bit keys (see just ahead for a discussion of key length); these variants are commonly known as AES-128, AES-192, and AES-256, respectively.
  • Blowfish. This fast, open-source encryption algorithm, designed by security expert Bruce Schneier, can use key lengths from 32 to 448 bits.
  • CAST. The term CAST is used for a family of algorithms; the name comes from the initials of its developers, Carlisle Adams and Stafford Tavar. The original version, with a 128-bit key, was called CAST-128 or CAST5; a modern successor is CAST-256.
  • DES. The Data Encryption Standard, which dates back to 1975, was formerly approved for use by the U.S. government and can therefore be regarded as a forerunner to AES. But it supports only 56-bit keys, and because it's been shown to be breakable with relative ease and speed, it's no longer considered secure.
  • IDEA. The International Data Encryption Algorithm, which uses 128-bit keys, is considered a highly secure cipher, and was designed as a potential replacement for DES.
  • Triple DES. Also known as 3DES or TDES, this cipher is based on DES but applies the DES algorithm three times to each block of data, thus increasing the possible key size to 168 bits (that is, three separate 56-bit keys).
  • Twofish. Designed by a team of cryptologists, including Bruce Schneier, Twofish is in the same family as Blowfish but considered more modern and advanced. Twofish can use key lengths up to 256 bits.

Passwords and Keys -- As previously mentioned, a key is a piece of information that a cipher uses to encrypt (and decrypt) data. If you encrypt two copies of the same data with identical ciphers but different keys, the resulting ciphertext is different; likewise, if you use the same key to encrypt two copies of some data with different ciphers, the results are different.

One form a key can take is a password (or passphrase). In other words, feed your password into an encryption algorithm to encrypt some data; then use the same password later to decrypt it. This example assumes a system in which the same key is used both for encryption and for decryption - a symmetric cipher. Asymmetric, or public-key, ciphers use one key to encrypt data and another one to decrypt it. A key can also be, among other things, a string of data stored on a token, a smart card, an electronic key, or another device.

An algorithm's key length is the longest key it can use. So, AES-128 can use a key that's 128 bits long. For those of you unaccustomed to thinking in binary, that translates to 16 characters. Likewise, a 256-bit key can be up to 32 characters in length.

When you choose a password for encrypting data, most encryption algorithms don't use the password itself as the key. Behind the scenes, the algorithms run your password through some mathematical functions that turn it into a number with the maximum key length the algorithm supports. This is done partly to protect your password from discovery (even if the key is cracked) and partly to make sure the key has exactly the right number of bits. If a cipher uses a 128-bit key but I enter an 8-character (64-bit) password, the software performs its magic to give itself a longer and more secure key to work with. That means if someone attempts to break the encryption by trying every key, that person has a much wider range of possibilities to test. But if, instead, that person tries to break the encryption by testing passwords directly (running each one through the necessary process to derive a key), he or she might break the encryption sooner.

On the other hand, if I enter a password that's longer than the supported key length (say, a 20-character password for a 128-bit cipher), the software typically discards the extra characters before deriving its key. The result would be that an attacker trying to decrypt my files by trying all possible password combinations would have just as much trouble as someone trying all possible key combinations.

The upshot of all this is that it's to your benefit to choose a password that's as long as possible - but no longer than the maximum key length supported by the algorithm you use. If you use 56-bit DES, a 20-character password is no safer than a 7-character password. However, with AES-256, a 32-character password is exponentially safer than a 31-character password!

For any given encryption algorithm, longer keys (and therefore, to a point, longer passwords) are more secure. However, as I stated earlier, not all algorithms are created equal. That means key length alone doesn't tell the whole story; one algorithm's 128-bit keys might be, in practice, just as secure as another's 256-bit keys if the 256-bit algorithm has flaws that reduce its effective strength. In other words, given the choice of a longer key length with a given algorithm, you should take it; but don't assume that cipher A is stronger than cipher B just because the former uses longer keys. For all practical purposes, any modern cipher with 128-bit or larger keys is secure against all but the most determined attacks - assuming you've chosen a good password.

Choosing What to Encrypt -- How much you encrypt or whether you encrypt anything at all depends on several factors, including where you use your Mac, how sensitive the information on it is, what other security measures you've taken (protecting against theft, for example), and what your tolerance for inconvenience is.

Needless to say, the greater the confidentiality of your data and the less physically secure your Mac is, the more important it is to encrypt data. But you shouldn't overlook the convenience factor. In general, the larger the unit of data you encrypt, the more convenient it is in the long run. That is, it's less bother (in some senses, at least) to encrypt your entire disk than to encrypt just your home folder; it's less bother to encrypt your home folder than to encrypt a conventional folder; and it's less bother to encrypt a folder than to encrypt a single file. That may all sound counterintuitive, but it has to do with things such as the amount of manual effort required to encrypt and decrypt files and how often you have to type a password.

However, also keep in mind that how and when you use encryption depends on context. For example, in some situations, it may not make sense to encrypt even a very sensitive file when it's sitting on your hard disk, but if you transfer it to a flash drive to take it with you somewhere or if you send it to someone via email, FTP, or some other method, encryption suddenly becomes quite important because you lose the security otherwise provided by your normal computing environment.

With those thoughts in mind, consider the following units of data you could potentially encrypt, all of which are elaborated on in the full chapter:

  • Individual files
  • Individual folders
  • A disk image
  • Your home folder
  • An entire volume
  • Your startup disk
  • A complete hard drive

As I describe in the book, there are good arguments for choosing any point along this continuum. The way you go about encrypting data depends on how much you want to encrypt and what combination of features and trade-offs works best for you.

Encryption Pitfalls and Misunderstandings -- Encryption can sound like a magical process that makes your data impervious to discovery. But merely encrypting something doesn't necessarily make it safe. Encryption involves a number of potential holes and hidden dangers, and if misused (or trusted indiscriminately), it can cause more problems than it solves. Before you embark on an encryption crusade, however worthwhile your ultimate objective may be, keep in mind the following possible gotchas.

Forgetting the Originals: In most cases, when you encrypt a file, you actually create an encrypted copy of the file, leaving the original intact. Even encryption programs that automatically delete the original after encrypting it often do so in such a way that the unencrypted file could later be recovered. Later in the chapter from which this excerpt is taken, I discuss secure deletion as a way to solve this problem.

Leaving Files Unlocked: Encryption protects data on your disk only when it's not actively in use. For example, your keychain is encrypted, but when you unlock it, you (or someone else) can freely access its contents until you lock it again or it locks on its own (based on your preferences). Similarly, if you encrypt a disk image, it's safe as long as it's closed, but when you mount it, its files become available to anyone with access to your computer. Therefore, you should always close, unmount, or lock encrypted files when they're not actively in use.

Choosing an Insecure Password: Poorly chosen passwords are the Achilles heel of any encryption system. Longer, random (or seemingly random) passwords do a vastly better job at protecting your data than short or easily guessable passwords.

Forgetting Your Password: The flip side of choosing an insecure password (which might let someone else get at your data) is choosing a great password but then forgetting it (which prevents you from seeing your own data). If you're not sure you can remember your passwords, store them in your keychain or in a third-party password management program.

Not encrypting everything that needs protection: If you're working on a secret business plan or composing an illicit love letter, it's easy to see why that one particular file should be encrypted. But one of the most common mistakes in data security is overlooking data that may not appear, at first glance, to be confidential but which can contain extremely sensitive information. Here are some examples:

  • Virtual Memory. As you use your Mac, Mac OS X constantly swaps information between physical RAM and virtual memory on disk to improve performance. The result, though, is that something you thought was only fleetingly stored in memory (such as text you copied to the Clipboard) can be stored on disk - sometimes for hours, days, or longer.
  • Your Clipboard(s). Speaking of the Clipboard, information that you copy or paste could be recovered, even if not stored in a virtual memory file, by using a cold boot attack (described in the book). And if you use any of the numerous utilities that offer multiple clipboards, they almost certainly store their information on disk long after you copy it.
  • Cache Files. Many applications, from your Web browser to your word processor, maintain cache files of recently (or frequently) accessed information to help them run faster. These cache files can contain a surprising amount of personal information.
  • The Contents of Your iDisk. If you're a MobileMe member, you should be aware that anything you put on your iDisk is unencrypted (unless you manually encrypt it), and therefore anyone who knows your MobileMe user name and password can access anything on it.
  • Backups. Some programs can store extra backup copies of your files as you work, possibly in locations you wouldn't expect. Also, some backup programs, particularly those that back up to Internet servers, keep caches of files on your disk, which may be unencrypted.
  • Spotlight. Apple's system-wide Spotlight indexes could contain cleartext traces of data from files you've encrypted. Some encryption programs expressly delete such data.

Encrypting Individual Files and Folders -- The most basic approach to encryption is to apply it only to the particular items that are especially sensitive. Although it would be extremely awkward to individually encrypt each file you use on a daily basis, encrypting specific files or folders makes sense when sending the info over the Internet (by email, FTP, or otherwise) or if you're using any other unencrypted transmission or storage method, such as employing a flash drive, external hard drive, or optical disc to move files from one location to another.

As mentioned earlier, it's important to remember that when you encrypt a file or folder, you actually create an encrypted copy, leaving the original intact and unencrypted. The same is true if you decrypt a file or folder, modify it, and then re-encrypt it. Therefore, the safest practice to follow after encrypting something is to securely delete the original; for example, by dragging it to the Trash and choosing Finder > Secure Empty Trash.

If this is the sort of encryption you want, you have many tools to choose from. Mac OS X includes command-line utilities that can encrypt files (as described in just a moment), although they're not terribly convenient to use. Numerous third-party vendors offer easy-to-use alternatives, with a wide variety of encryption algorithms, interfaces, and extra features. Regardless of which type of program you use to encrypt your files, consider the following factors when choosing an encryption tool:

  • Compatibility. Will someone else have to decrypt this file - or will you have to decrypt it on another computer - and is suitable decryption software available on the target computer? If you choose a Mac-only encryption program, for example, the recipient will be out of luck if she has only Windows available.
  • Convenience. How well does the program's interface fit in with your workflow? Be sure to download the program and try it out a few times with test data before committing to it for live use.
  • Sending a Password. The most securely encrypted file isn't secure at all if an attacker or thief learns its password. So, if you're sending an encrypted file to someone else, you must also find a secure way to let him or her know how to decrypt it. Sending a password in a cleartext email or writing it on a slip of paper is an insecure method. Better methods include sending it in an encrypted message, using Skype or another encrypted instant messaging service, or delivering the password orally in person.

Encrypting Files on the Command Line -- You can encrypt individual files using the openssl program included with Mac OS X, as long as you don't mind getting your hands dirty on the command line. Basic instructions follow; for more detail, enter "man openssl" in Terminal.

To encrypt a file with openssl, follow these steps:

  1. Open Terminal (in /Applications/Utilities).
  2. Choose an encryption algorithm. Openssl supports dozens of ciphers, and your choice is significant in that you must know which cipher was used to encrypt a file when you want to decrypt it later. To get a list of available ciphers, enter "openssl list-cipher-commands". In this example, I use des3 - that is, Triple DES.
  3. Enter the following line. Substitute des3 with your preferred cipher. The first filename is the name of the file you're encrypting, and the second filename is the name of the resulting, encrypted file.
  4. openssl enc -des3 -salt -in filename -out filename.enc

  5. When prompted, enter and confirm the password. Openssl immediately encrypts the file.
  6. To decrypt the file later, enter the line below. Again, substitute des3 with your preferred cipher, and replace the filename references with the actual filenames.
  7. openssl enc -d -des3 -in filename.enc -out filename

  8. When prompted, enter the password used to encrypt the file.

Encrypting Files and Folders with Third-Party Software -- Of the many Mac OS X applications that can encrypt individual files and folders, I've selected a small sampling to give you an example of your options:

  • BitClamp. BitClamp compresses individual files using your choice of AES-256, 256-bit Serpent, or 448-bit Blowfish algorithms. Drag one or more files into the window, click Encrypt, enter and confirm a password, and you're done. To decrypt files, double-click them and enter your password. ($19.95)
  • Drop Secure Pro. Drop Secure Pro is available for Mac OS X, Windows, and Linux. As the name suggests, it lets you encrypt files, folders, and raw text by drag and drop. It offers no fewer than 15 encryption algorithms, including all the usual suspects (such as AES, Blowfish, IDEA, and Triple DES). You can optionally compress the items you encrypt using gzip or bzip2 compression. ($57)
  • FileWard. This easy-to-use utility, which relies on the openssl tool built into Mac OS X, lets you encrypt files and folders as well as the contents of the Clipboard by drag and drop using any of the following algorithms: Blowfish, Cast5, Triple DES, DES-X, AES-128, or AES-256. After encrypting files, it securely deletes the unencrypted temporary files created by openssl. ($9.99)
  • PGP Desktop Home and PGP Desktop Professional. These security packages, which I discuss in more detail in the book, offer a variety of ways to encrypt data. Among them is the option to encrypt individual files or folders, either with a password or using public-key encryption, which can eliminate the security concerns associated with sending someone else a password to decrypt a file. (Home version, $99; Professional version, $239)
  • StuffIt Deluxe. This suite of file compression tools has existed, in one form or another, since the early days of the Mac and is also available on Windows. In its current version, you can compress and/or encrypt files and folders using either StuffIt Archive Manager or DropStuff (the latter of which is designed for quick drag-and-drop operations and also lets you create droplets - stand-alone applications with specific combinations of compression and encryption settings for particular tasks). With these products, you can encrypt files in the StuffItX format using any of four algorithms: 512-bit RC4 (the default), 64-bit DES, 448-bit Blowfish, or AES-256. You can also use StuffIt Deluxe to encrypt ZIP files (using only the AES-256 algorithm), but because of the way the ZIP format handles encryption, someone could see the names of the files and folders in an encrypted ZIP archive even without decrypting it. ($79.99)

There's another category of software that can encrypt individual files and folders, but instead of storing them separately on disk, it stores them in a proprietary container, sometimes known as a vault. Often, such programs are used to secure not only files but notes, passwords, credit card numbers, and other random snippets of information. Obviously, such programs are more appropriate for securing data for your own use than for sending it to others. Two examples of software in this category are:

  • AllSecure. This snippet keeper can store files, folders, notes, and other confidential information. When you add files to AllSecure, they're ZIP-compressed with AES-256 encryption. ($25)
  • Yojimbo. Yojimbo is a popular repository for random information of all kinds. When you store files or text notes, you can optionally encrypt them individually using AES-256 by clicking an Encrypt button and then typing your password. To view an encrypted item, click the View button and then enter your password; to decrypt it permanently, choose Item > Decrypt and then enter your password. ($39)

More Encryption and Beyond -- That's just the beginning of what I cover in the chapter on encrypting files. I go on to discuss working with encrypted disk images, using FileVault, encrypting an entire disk, using hardware-encrypted drives, securely deleting files, securely erasing disks, and recovering deleted files.

And, of course, encryption is only one of a great many topics pertaining to Mac security that I explore in the book. It also includes complete details on secure email, chat, and Web browsing; protecting your Mac against malware; network security; sharing your Mac's resources safely; securing Mac OS X Server; and dozens of other subjects. If you're interested in Mac security and want the ultimate all-in-one reference, I think you'll find the "Mac Security Bible" to be a valuable reference. The retail price of the book is $49.99; offers it for $31.49 at the moment.


READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <>
Special thanks to Jonathan Levine, Dan Locke, Anne Nieman, and John
Martin for their generous support!

Comments about An Introduction to File Encryption in Mac OS X
(Comments are closed.)

Murali  2010-04-11 14:57
I use Knox, which utilizes and extends the Mac's encrypted disk images feature and extends that functionality with a menubar app that permits fast switching amongst vaults, lets you enable or disable Spotlight indexing of vaults on a per-vault basis, and lets you rename, move or change passwords easily. The app is one of those longstanding Mac apps that works beautifully but gets little attention -- it first came out 5 years ago and has been periodically updated.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-11 15:01
Yes, I mention Knox (and a number of other third-party utilities) later in the chapter from which this article was excerpted.
Glenn Fleishman  2010-04-11 17:29
There's some suspicion, voiced in parts of the security world, that the US government has an effective probably brute-force crack for AES-128, for a variety of reasons, but partly because government agencies must use -192 or -256.
David Weintraub  2010-04-12 09:00
How would encryption work with things like Dropbox?

It'll be pretty bad if all the files in Dropbox were encrypted and couldn't be opened on other computers that share your various Dropbox folders.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-12 10:53
You'd have to encrypt files using a method that was supported on all your computers, and for which they all had the appropriate software installed.
Lenard  2010-04-12 09:47
You forgot to mention
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-12 10:54
I didn't forget :-). Like Knox, Espionage is covered later in the chapter from which this article is excerpted.
Derek Currie  2010-04-26 21:50
GPG: As a free alternative to PGP is GnuPG, aka Gnu Privacy Guard. A beta bundle for Mail was released this past month to make it compatible with Snow Leopard. It jumps through all the usual security hoops as well. I use it for mail signing and encryption. I can happily post the range of links to the various utilities upon request, or Google it.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-27 00:02
Yep, I talk about GPG at length in the book.
Burkhard  2010-04-27 01:01
You seem to say that each character in a passphrase contributes 8 bit to the encryption key. But this would only be true if people used all possible character values in the range 0 to 255. However, the actual number of input bits in the keyphrase does not have anything to do with the encryption key, since good encryption algorithms don't use the keyphrase directly but apply a hashing algorithm to it.
Typically, good passwords use about 64 characters, poor ones at most 32. This effectively reduces the search space for a brute force attack, and may also help in other forms of attack. Therefore one should assume that each character contributes only 5 to 6 bits to the encoding key. You get an even lower expected number of bits if you do statistical analysis on the frequency of certain characters.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-27 01:08
I talk about things like entropy in much more detail in the book. Keep in mind that a brute force attack can't know, a priori, which characters you've used. So as long as you follow some basic rules about which types of characters to use in a password, 32 characters won't give you any better real-world security than 11.
Julian Y. Koh  2010-04-27 05:29
Nice article as always! One tiny nitpick - the effective strength of 3DES is 112 bits, not 168.
Joaquin Miller  2010-04-27 19:18
I'm surprised you did not include TrueCrypt in the TidBits excerpt. Do you agree it offers features none of the other programs offer? It is certainly extremely easy to use.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-28 00:56
I cover TrueCrypt in the portion of the chapter dealing with encrypted disk images rather than this part, which was about individual files.
Andy Burki  2010-04-28 05:50
Your article, interesting as it is, is very truncated and every few words you feel the need to mention that you have the complete thing in the book. It just comes across as one huge plug for your book and as such I feel is not a welcome part of a Tidbits issue. I hope we won't have to bear with such things in the future. I appreciate your other contributions and TakeControl books enormously.
Joe Kissell  An apple icon for a TidBITS Staffer 2010-04-28 06:08
The chapter from which this excerpt was taken was far too long to work as a TidBITS article. We had to make some difficult decisions as to what we could include and what we had to cut, so unfortunately some truncation was unavoidable.

There were many places in the chapter where I said things like, "...but I explain more about this later in the chapter, under such-and-such a heading," and since that obviously wouldn't make sense in an article that didn't include those pieces, I instead changed those references to say that you can read the rest of the story in the full book. Also, as the comments show, readers already assume I forgot about, or somehow failed to mention, various important facts and programs, and some of the references to the book are intended as reassurance that the material really is there!

That said, the purpose of putting this excerpt in TidBITS was twofold: to convey useful information, and - yes! - to plug the book. I don't think that's in any way inappropriate!
Adam Engst  An apple icon for a TidBITS Staffer 2010-04-28 07:42
Joe's comment above exactly spot on. We often run excerpts from book our staffers write, and he and I went back and forth on a number of ideas before settling on this one as providing a necessarily truncated subset of useful information - this is a 900-page book.

It is too bad that it seems many people - upon reading the article - immediately thought "What about Product X?" As anyone who has read one of Joe's Take Control books knows, Joe is incredibly thorough, and every one of those products is discussed in the full book - there was just no way even to list them all in this article and keep it within a reasonable length.