448 bits is quite a lot of entropy. In order to match the security of the key, the passphrase must provide a similar level of entropy. If there is any significant difference in entropy between the two, an attacker will just go for attacking whatever has less entropy.
I don't recall the exact figure, and it probably varies with language, but natural language has between 1 and 2 bits of entropy per character.
So to get to a similar level of security as a truly random 448 bit key, you'd need a passphrase of, on the order of, 300 characters. It also must not be known to anyone else, or have been used by anyone else, so famous quotes, quotes from your favorite books, and so on, are pretty much out of the question. That'd likely be the first thing someone would throw their cracker at trying to use.
For comparison, to get the required level of entropy, you need a passphrase of approximately the length of the preceding paragraph. And you must be able to type it 100% correctly, every time, quite possibly without seeing what you are typing.
With a truly random password made up from an 85-character set (say, the Base85 set), you're looking at about log2(85) ~ 6.4 bits per character. So to get to 448 bits you'd need about 70 truly random characters from an 85-character set.
Disregarding the question of whether the entropy pool has that much true entropy to begin with, you need to be able to remember the password, and keep it secure. I would dare you to remember even a single 70-character truly random password consisting of virtually every printable character in the ASCII set.
There's also the question of what attack vector someone will choose. Nobody is going to attack a 448-bit key through brute force trial and error decryption attempts; doing so is simply out of the reach of humanity at this time, and quite possibly forever, due to simple physics. Any attack on such cryptography is going to be through other methods, whether side-channel attacks, rubberhose cryptography (as exemplified by XKCD), outright theft (don't laugh!), cipher attacks more efficient than brute force, or something else. It's a lot easier to hire a few thugs to break into your home and steal your laptop, than to attack properly implemented even 128-bit symmetric cryptography.
Which leads us to:
It seems like the difference between option 2 and 3 is that, which option 3, there is the onus of me needing to keep a copy of this keyfile, which is cumbersome (vs. a password). My question is this: how much more secure is option 3?
In practice, with both options (secure password encrypting the file locally, and secure keyfile encrypting the file locally), you are going to have to safeguard a copy of the key material. So from the "how cumbersome is it?" point of view, they are roughly similar. From the security point of view, it comes down to the amount of entropy in the secret material (keyfile or passphrase).
So:
If you are worried about someone gaining access to your files on Dropbox, then use a locally stored key file and encrypt the files before uploading. It will be more convenient for you, but if an adversary is able to gain access to your computer, they will of course have the key file. You may be able to partly work around this by combining a key file with a simpler password or passphrase.
If you are worried about theft of your computer, then use a strong passphrase which does not exist and has never existed on your computer outside of that specific use. It will present greater difficulty for an attacker, since they will need to convince you to reveal the passphrase. Note that doing so need not be difficult; a few hints about what happens to people protecting terrorists, or a hint to a few well-placed media connections that a person matching your description is being investigated for child abuse, or something like that, might be enough.
If you are worried about both, then use both, assuming that the software allows you to do that.
Best Answer
Disclosure: I am the CEO and a Founding Partner of Code42
It's overkill. To make matters worse, it'll slow down your backups and delay data protection as the realtime monitoring wont work and encrypted data isn't compressible.
By using private data password (recommended) or generating your own key, you are ensured privacy. (Yes, you have to trust us on saying this, but unless you're a software/security expert personally studying/auditing the truecrypt code, you've got to trust something/someone.
If you have data so precious you can't trust anyone, doubling up encryption is reasonable. However, I'd only do that for that specific set of data - let CrashPlan handle the rest.