To answer your first question about the keychain and whether you should encrypt backups: the passwords in your keychain are already encrypted, that's why you always have to type a password (by default your login password) to show stored passwords. So there's no immediate need to encrypt.
Of course, you could add Time Machine encryption to provide a further layer of security. This is possible starting with OS X Lion and Mountain Lion (from http://support.apple.com/kb/ht1427):
OS X Lion and Mountain Lion let you encrypt the Time Machine backup
external drive using FileVault 2.
FileVault2 also uses your login password, though. So if the bad guys are able to guess or crack that password, they will have also access to your keychain information. Choosing different passwords for login and for accessing your keychain would protect the keychain passwords in such an event.
Either way, use strong passwords, password quality is of foremost importance to protect your data.
EDIT:
The OP asked in a comment how to set different passwords for login and keychain. Here is how:
If you prefer to use your current password as keychain password and change your login password, log in using another account and change your account's password from System Preferences>Users & Groups. That will only change your login password, not your keychain password.
No, sorry chickpee, I believe you're incorrect.
Is an encrypted Time Machine disk really just the same as a normal
disk, full-disk-encrypted using FileVault?
Yes. It is. This would be "FileVault 2" we are talking about, aka CoreStorage, Apple's newish logical volume manager. This is different that the previous TM and FileVault technologies, which are based on AES-encrypted sparse-bundle disk images (which are still used for network backups, etc.). The process that starts in System Preferences (these days) when you enable disk encryption (whether on an external disk, for Time Machine, or on the boot drive for FileVault), provided the disk is suitable, it does an online conversion from a traditional GPT Partition Table to a single monolithic data store, with a very small partition for the CS firmware. Logical volumes (in logical volume groups) are then carved out of this, and these (software) volumes are then HFS formatted and encrypted.
I believe the most straightforward method for doing this would be to:
- Attach the disk you're going to use, wipe it. Free space or a single HFS+ partition.
diskutil cs create/convert (wasn't/was formatted; unimportant) to initialize and add a new LVGdiskutil cs createVolume, create a single LV. You could enable encryption at this point, with diskutil cs encryptVolume, if you know the passphrase you're going to use;
if not, leave it unencrypted for now.diskutil partitionDisk diskX -- see below -- CS volumes appear as if they are completely autonomous, separate disks, so you partitionDisk.
Then: mount and unlock the volume on your new user's machine. Once the disk is unlocked, there shouldn't be any trouble 'adopting' it for use there. If you want to put it into a config script, I believe it's just something like tmutil -a /Volumes/Foo, tmutil startbackup -ad disk.... This is the part I'm least sure about, but I'm also sure its easily doable. I haven't done this for Time Machine per se my self, but I pre-encrypt disks for FileVault like this all the time, and the OS sort of just knows what to do with if after that.
A properly suitable CS-enabled-disk is going to appear like this in diskutil (although you might not have the third partition on disk0 if it's knows it's not going to be a boot drive:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 250.1 GB disk0s2
3: Apple_Boot Boot OS X 250.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh LV *249.8 GB disk1
disk0 will not appear as encrypted, ever, since this is what the volume manager basically has to 'boot' off of. disk1 will be encrypted and will require the passcode to mount.
Best Answer
Actually your mac is capable of encrypting that fast (perhaps you're confusing it with encryption+compression).
Your processor has a special Intel AES-NI instruction set, specifically designed to optimize encryption speed. Looking at some performance benchmarks for that processor, the AES test performs at a whopping 8.87 GB/s multi-core and 2.94 GB/s single-core. No bottleneck there, but I can imagine some latency from processing thousands of small files instead of one big one like in the benchmark.
To address the confusion in your question: