Slashdot Mirror
Why Not Use Full Disk Encryption on Laptops?
Saqib Ali asks: "According to the 2006 Security Breaches Matrix, a large number of the data leaks were caused due to stolen/missing laptops. Mobile devices will be stolen or lost, but one way to easily mitigate the harm is to use Full Disk Encryption (FDE) on all mobile devices. So, why don't we encrypt all our HDDs?"
"Cost, and performance impact are the usual arguments.
Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time. With FDE, the swap file (system's virtual memory) gets encrypted as well. This will impact the system's performance noticeably when the virtual memory is being used more often.
Encryption key & password management blues follow. What happens when the user forgets his/her new FDE password? How to manage the encryption key backup files? Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys? Who can access the system and its encrypted files? How frequently does the password need to be changed? How to prevent the user from writing the passwords down? Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Cost for Full Disk Encryption solutions ranges from $0-$300.
Is it not worth using Full Disk Encryption on mobile devices after all the data leaks we have seen in the last few years?"
Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time. With FDE, the swap file (system's virtual memory) gets encrypted as well. This will impact the system's performance noticeably when the virtual memory is being used more often.
Encryption key & password management blues follow. What happens when the user forgets his/her new FDE password? How to manage the encryption key backup files? Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys? Who can access the system and its encrypted files? How frequently does the password need to be changed? How to prevent the user from writing the passwords down? Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Cost for Full Disk Encryption solutions ranges from $0-$300.
Is it not worth using Full Disk Encryption on mobile devices after all the data leaks we have seen in the last few years?"
If the summary answers its own questions why even bother posting comments? Except to be a smart-ass (like me).
Philosophy.
Really, we all know that people will forget/lose the password. Or they'll write it down and leave it in the laptop case.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Doesn't Vista have a built-in feature for full disk (or all but system files) encryption? Can't you even just check off the 'encrypt' option on the properties sheet for your my docs folder (even on XP) ... or your entire user profile (to cover outlook OST etc, though that is already encrypted I believe, or can be configured to be in outlook).
Most of the key management problems have actually been solved. PGP disk for a long time had the ability to encrypt using multiple keys, fraction keys (eg. 3 out of 5 must have their keys to open), key expiration, etc.
The real problem is convenience. People don't like to use secure passphrases each time they turn on their computer. How many people actually used the BIOS password feature? An easier thing would be to use some identification based (USB fob, fingerprint scanner) access, but the acceptance rate of those are very small.
Unless security is important to them personally, people just don't care. (checking under my keyboard for the root password for all the machines at work)
Will the War in Iraq get better or worse in 2007? Vote here
I for one, do use full encryption... Suits me just fine...
But then again, I use linux. Encryption is actually pretty simple under it for people who actually know how to admin a Linux system.
At one time, I even ran Win2k under VMware from an image on the encrypted disk. Which means the *ENTIRE* win2k "partition" was encrypted -- something that I understand to be impossible when run natively.
The real reasons why most don't do it?
1) Ignorance -- it is not a built-in feature in Windows
2) Hassle -- overtasked IT professionals aren't going to incur extra liability for encrypting a disk, handling lost passwods, etc. (It would be really bad to forget the password)
3) Performance -- Encrypted disks aren't good for high I/O apps... Fortunately, most apps aren't!
I sleep much better, knowing that my data is safe even if I loose possession of it. I have no qualms about storing tax returns, financial records, etc on my laptop.
Granted, I am not encrypting the *whole* thing, but /home should take care of most of the sensitive data. I am using GBDE on FreeBSD which is strong enough for the weakest point to be the password. Yes, if I do lose the password, the data is unrecoverable. However, a simple way around this problem is to regularly back up the entire partition. The backup should be unencrypted, of course, so that if I lose my password, I can still get back my data. With GBDE, this is easily done. The encrypted data on my machine resides in /dev/da0s1g and after I have typed in the password, the decrypted content appears under /dev/da0s1g.bde - all I need to do is dump that partition.
Certainly, encrypting all other partitions would increase security, but I am feeling pretty safe as it is. Also, FreeBSD is probably obscure enough for most laptop thieves by itself :). One last thing to note is that because the file system on *NIX is well structured, there actually should not be any sensitive data anywhere in /usr anyway - just application binaries and source.
System Preferences -> Security. Click "turn on file vault". A few minutes later, you're done.
Also check "Use secure virtual memory" (aka encrypt swap) on the same tab.
Now swap and your home directory (so all important data) is encrypted. The OS and applications are not. As a result performance degredation is minimal.
In the business enviornment the business can set a recovery password in case the user forgets, dies, whatever. The user's login password is the only password they need.
Free. Easy to use, you do nothing. Minimal performance impact. So the real reason most people aren't doing it? They are stuck with Windows bloatware or are ignorant.
What do you mean "Why don't we use full disk encryption?"
The company I work for(financial services) has been using this for over a year now. Not just on laptops, but also all desktops in the company.
Full Disk Encryption gives you the access overhead that comes with encryption/decryption for every access to the hard disk. Why not just encrypt the sensitive data if you want to avoid leaks of the sensitive data?
Plus, a lot of the recent newsworthy leaks would be avoided or minimized by using encrypted access to sensitive databases via an application on the laptop, rather than people copying large databases of sensitive data to their laptop to take it home and work on it, and then losing the laptop.
and it has been around since Win 2000.
p pro/deploy/cryptfs.mspx for more
It's not really "full disk" encryption, as it applies to a single file or folder.
See http://www.microsoft.com/technet/prodtechnol/winx
This post written from a laptop with a LUKS-root filesystem. I catted a 280 MB file into dev null, it took 17.8 seconds. I copied that file to a filesystem on the exact same drive, umounted the filesystem, remounted it, and tested that, it took 12.5 seconds Top showed the crypt activity as taking about 50% of my cpu in the first case, my Pentium M at the time of measurement clocked only up to 800 MHz to accommodate the load. This test was repeated a few times with a small degree of variation.
/, and didn't notice a problem at all.
Anyway, those metrics are actually more different than I would have expected. I was hoping to demonstrate that the difference isn't that much, but objectively it is disk io performance hit. In general use I don't notice it. I already had a crappy hard drive that was dog slow, and in the end adding encryption made it... still a crappy hard drive that is dog slow, and the extra slowness I didn't even bother perceiving until I tried to measure it. I used this laptop for a few weeks with no encryption, and on the next install did encryption from the get go on everything from
XML is like violence. If it doesn't solve the problem, use more.
Proud member of the Weirdo-American community.
In the context of stupid employers/empoyees losing laptops with sensitive databases on them, this isn't even a question - the data should never leave company premises unless it's encrypted, end of story. The fact that this isn't standard practice indicates widespread incompetence.
A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems:
k start.html
http://ecryptfs.sf.net/
eCryptfs is an actual filesystem operating at the VFS layer of the Linux kernel. It stacks on top of other filesystems like ext3 and encrypts files one at a time, with each file getting its own key.
Who cares about encrypting libc or the x.org libraries? People want to encrypt their financial, medical, and other such data. eCryptfs makes it easy to encrypt only what users want to encrypt.
Some ways that eCryptfs deals with the issues raised:
What happens when the user forgets his/her new FDE password?
The best answer is, ``You're screwed.'' That is the way it should be; without the secret, nobody -- not even you -- can get to the data.
Now, out here in reality, things can't be quite that convenient. Try telling the CEO that his third-quarter reports are lost forever. The next-best thing is intelligent key escrow. I tend to recommend (m,n)-threshold sharing, wherein a certain number of people in a group need to collude (say, 3 out of 5 people in the company) in order to reconstruct the secret value.
eCryptfs userspace tools have a pluggable key management infrastructure, and thus it can keep the secret value in any token device for which a module exists. These hardware devices do not need to be expensive. In fact, Thinkpads come with TPM chips built-in, and a TPM key module already exists for eCryptfs:
http://trousers.sourceforge.net/tpm_keyring2/quic
How to manage the encryption key backup files?> Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys?
All of these are addressed with something like (m,n)-threshold sharing:
http://en.wikipedia.org/wiki/Secret_sharing
Also, because eCryptfs encrypts on a per-file basis, an incremental backup utility can just access the encrypted files on the lower filesystem. All of the information needed to decrypt the files is right in the header of each file; all you need is the key.
Who can access the system and its encrypted files?
This is a semantic security problem that the tools should definitely address. eCryptfs, in its current form, provides fairly flexible key management options, but the design goals of eCryptfs are much more ambitious, and they seek to address these sorts of issues:
http://ecryptfs.sourceforge.net/ecryptfs.pdf
How frequently does the password need to be changed?
Ideally, one would use eCryptfs in public key mode, so that is largely a non-issue. The secret can remain locked in a TPM chip, and the key can be escrowed.
How to prevent the user from writing the passwords down?
There is nothing wrong with writing passwords down, as long as the paper on which the passwords are written is stored in a location that can be made at least as secure as is necessary to protect the data that the passwords are protecting. In any event, the secret value can depend on a password *and* something else, like a file. The OpenSSL key module can be used in that way.
Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Not really; many laptops shipped today have TPM chips built-in.
Oh, yeah, and all of eCryptfs -- both the kernel and userspace components -- are GPL. Give it a try.
An unjust law is no law at all. - St. Augustine
This is slightly off the topic, but in the same vein...
I continue to wonder, after every major laptop theft, why NOBODY is working on physical security.
Notebook hard drives are easily pocket-sized, and the only thing keeping the hard drive from sliding out of most laptops is the thin plastic shell of the unit. Build laptops with a very simple hinging door over the drive would be absolutely trivial. You probably also want to add thin aluminum shell around the drive to protect it from static discharge and other abuse.
Then, you tell employees to keep the drive in their pockets when they go into public. If it's really critical data, attaching a retractable cable (as seen attached to your janitor's keyring) between your belt and the drive will stop all but the most skilled, equiped and determined theives.
It's as if everyone in IT has forgotten the lessons learned from the past several thousand years of (physical) security developments.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
To encrypt entire disk it is a stupid idea. Few points:
- Performance - encrypting everything (cache, program files and so on) is a serious hit on performance, now you can say that hardware/performance it is not a problem. But don't say it to me when I see brand new laptop booting long time since you can login and launching MS Office in *few* seconds.
- Anyway why encrypt everything when it is the data (and not all of it) that you want to encrypt?
- Hassle - I mean when it is an option to just tick "encrypt my harddrive" checkbox it is paradoxically way to easy. You can imagine every clueless marketing staff member just ticking it to encrypt their worthless data. It is good that hard encryption is bit "hard" (like you need to provide a password and a key and have a clue what is going on) so people will use it only when they need it, so they will probably remember their passwords.
My boss asked me for this feature. I've just installed TrueCrypt for this. Told him to click on this icon and *remember* his password (probably he wrote it down and locked in a safe - perfectly normal and wise) so he can get his "special safe disk" for his important documents.
I'm going to use LUKS as my example, since the classic cryptoloop and older dm-crypt stuff can't do this.
The solution is for IT to have a person perform the install (already was going to be hard not to do so with the current state of installers). The IT person makes a master copy of the key using the company's chosen password, and uses a different key slot for the employee-known password. When password changes occur, IT people have to go and change the IT-friendly key slot to the new password, but leave the employee's alone. Then IT can recover data from laptops at user requests. This doesn't guarantee data recovery from a system if the user who can change the password on their own key slot doesn't want them to, but if the user wants to play nice to keep IT able to assist them it can work. If the user botches the IT key slot and needs recovery, tough. Data on a laptop in that circumstance should be relatively transient if remotely important, with the real copies on file servers where IT can manage backup and recovery as they see fit.
At work the mandate for Windows laptops is to use the built in encrypted folders mechanism, which is a lot like encfs. If they loose their user password for the account the data is gone, and this is just a fact of life they have to live with. One person went further and put some third-party whole disk encryption on their Windows laptop, a la dm-crypt, but I don't know if it is like classic dm-crypt setups where the key itself is simply a hash of the password, or if it is LUKS style, where the key is random (or at least psuedo-random) and itself is encrypted using the hash of passwords, allowing for trivial password changes and multiple valid passwords.
XML is like violence. If it doesn't solve the problem, use more.
All the fingerprint and user authentication in the world is a poor defense against someone ripping out the drive, which is easy if the laptop is stolen. That's why it is generally a larger issue on laptops than desktops. Desktops tied to your desk at work have whatever physical security the company has invested in protecting it, leaving it open only to the possiblity of remote attackers (well, within reason, the physical security can be bypassed, but assume a perfect company for discussion). The whole threat of a laptop is physical security breaches, otherwise the discussion wouldn't be laptop-centered. As to not putting confidential stuff on laptops, it is a good idea, but that is a policy rooted in trusting the user to always be vigilant about the confidentiality of the data set they are working, trusting their judgment, and expecting them not to take convenient short cuts at 5pm on a Friday so they can get it done on the weekend without staying late or looking bad on Monday. I use full disk encryption so I don't have to even think about it. I'm fairly sure I have nothing on my laptop remotely of interest to anyone, but I never have to think too hard about it.
XML is like violence. If it doesn't solve the problem, use more.
Do you understand what's being discussed here? It's NOT how to keep your laptop from being stolen. It's how to protect its contents in case it IS stolen. Not trying to prevent theft -- trying to make sure your data doesn't fall into the wrong hands.
I work as a SW consultant for the mobile sector and all laptops in our firm have encrypted hard drives. The system is so that username and password is asked right when the laptop is booted kinda like bios password and after windows is loaded it automatically logins you to windows with those credentials. It's easy to use, no need to remember any additional passwords and also added benefit is that the administrators can login into it with their credentials if a user forgets his password.
:).
The performance hit is real and noticeable though, but mostly affects hard drive related tasks, so that does not hinder my working too much.
Also all firms that I have been dealing with use encrypted laptops, so in my perspective the FDE is pretty widely used already
...for a 7 week gig at a semiconductor maker. IBM (yeah, now Lenovo) Thinkpad, and I had to enter a password at boot. No sweat, they asked me to give the password to the tech who received the equipment when I turned it in, but it could have been reformatted since I kept nothing on the local drive worth saving.
For what it's worth, this gig was all wireless on campus too, with VPN inside and outside the firewalls. I'm doing a long-term gig with a major financial firm now, and they don't use FDE. And they have NO, repeat NO NO NO wireless. The security team trolls constantly for unauthorized wireless and anything that transmits is confiscated as soon as they find it - cut out and trashed.
Both these firms suffer the same risks for their data. Either would suffer financially and risk complete failure if a critical breach ocurred. Just different ways of doing things.
deleting the extra space after periods so i can stay relevant, yeah.
Encrypting your whole disk on Linux is somewhere between a minor pain and a complete nightmare. Support for it doesn't even exist on certain high-profile commercial distros (Red Hat) which you would THINK would have had it long ago because it's something their customers would want.
I had to put together my own unofficial packages to get an encrypted root filesystem on Fedora Core 5. (And then it broke on FC6, so no upgrading yet...) In theory, the support will officially be in Fedora Core 7, but there's still a bunch of code to be written between now and then.
How am I supposed to fit a pithy, relevant quote into 120 characters?
http://forums.pgpsupport.com/viewforum.php?f=54&si d=749efb5b59855bac7e1a06eda016e4a9
If you need a reason why people aren't encrypting their disks, visit the PGP Whole Disk Encryption forum and take your pick.
-----
PGP Key ID 0xCB8FF658
In a number of contexts, loss of data is a more serious concern than loss of confidentiality. For the vast majority of self-generated data on my hard drive, I would be seriously inconvenienced by the loss of the data, but would not at all mind the data becoming public. For a significantly smaller amount of data, I would seriously mind the data becoming public, but I would more mind losing the data. Only a very small fraction of data on my computer is such that I would mind the data becoming public more than I would losing it.
In such a context, given that FDE makes data recovery harder and more time-consuming, it can make sense to encrypt only that tiny fraction of data where one would more mind its becoming public than one's losing it. In other contexts, it will be different.
I'll inform all the buyers of low cost paper weights on EBay that they're missing this important feature of the IBM laptops.
While yours is a true statement for some laptops, it isn't a blanket statement for all laptops. There are many exceptions to the rule that BIOS/HDD laptop passwords are easy to break.
You're reading Slashdot. Of course you like Linux and pc hardware
Based on the readme, it looks like encfs (which uses fuse and openssl). It might obscure more detail (i.e. with encfs you know how many files and directories there are, and their timestamps). How does it differ from encfs (http://encfs.sourceforge.net/)?
/boot (which I do). This has benefit for protecting against physical threats and people trying to reboot your system using a live cd or other such attacks. However, the key is always available to the kernel and all the data is visible, so a remote or local attack that acheives root privileges means all the data is exposed since a very coarse grained attack was used. On the bright side, it is also appropriate as a codified standard because users can't generally be trusted to correctly perform risk assessments on every save or understand all the temporary places they may save to, and it's the only way to protect swap patitions. I use dm-crypt with LUKS partitions for / and swap on my laptop, with a small /boot for the kernel and luks-enabled initrd.
/tmp is always exposed and swap is still dm-crypt protected on that system.
encfs is of course per user, and a somewhat nifty thing there is the pam_encfs module which can optionally used to get the authentication token to unlock its key. The implementation (since it's obviously has to be since it's a fuse thing) is more userspace than ecryptfs, but functionally speaking, what's the difference?
I understand well the benefits compared with dm-crypt strategy based on the circumstances and requirements.
With block level strategies, you have to decide the total size of the block device for protected vs. non-protected data. If you don't understand your needs well, it's difficult to apply a finer-grained approach to security, particularly if you are required to codify it into a company standard for people who you definitely won't understand perfectly the needs of. Because of this, the only generally feasible approach is to encrypt everything save for
encfs and similar strategies feasibly allow finer grained policies to go into place without making the tough size decisions as is needed with block strategies. This provides all the protection from theft and such like dm-crypt does. And if the policies are fine grained and the directories are only mounted as needed, a remote attacker achieving root access will only be able to get to file systems currently mounted, which may be a smaller set than the whole. The difficulty here is that when defining a finer-grained policy, you have to know which directories could ever hold sensitive data, If you are to protect swap you can't use a swap partition, but a swapfile in a directory protected by such a scheme, and in the end on a single user system (almost all laptops), effectively no matter what all the encrypted filesystems will be mounted anyway most all the time, so it's really not ultimately much of a functional difference. I make encfs available on a couple of multi-user systems, and generally have pam_encfs there to make their home directories encrypted.
XML is like violence. If it doesn't solve the problem, use more.
The traditional method dm-crypt and cryptoloop used was basically what you say, a hash of the password was used to encrypt the entire disk. Of course, no one ever devised a way to change the password in place, and even if they did, it would require all data on the disk to be re-encrypted. The key used to actually encrypt the data would likely be cryptographically weaker to crack, in theory. If you ever ever write down the password (I don't but some do) and then lose the paper, you can never be sure about the security of your data again short of re-encrypting the whole thing. I think this is probably the single thing people not researching it thoroughly misunderstand, if the technology you see is definitely encryption of a large data set, and you can essentially instantly change the password protecting it, the key used to encrypt the actual data is certainly not the password itself, as it requires a huge amount of effort to change the key on large amounts of encryted data.
In the LUKS scheme the key material used for the very large data set will probably be more cryptographically sound. With a large data set, cryptographically weak keys could more likely be crackable than strong keys, in a large number of the type of attacks historically seen in cryptography. A small data set (data comprised only of the actual key) is generally more resistant to data analysis attacks, so a somewhat weaker password hash based key may be less exposed in that context. If you ever think a malicious user has had opportunity to get your password (the most likely thing in general for an attacker to get), you can change the password and the old key slot be shredded such that the knowledge obtained becomes useless. Sure, the 'master password' being compromised would mean the disk is irrevocably compromised, but that would be the case in the classical strategy anyway, since changing the password isn't feasible. Now if you want to actually re-encrypt data in the way a password change would require in the previous example, you can always reformat with a different key (or re-encrypt in place if implementation allowed), and have the same degree of 'changing the master password' as you put it.
Keep in mind the 'master password' (or rather the actual key) in this context is probably a random 256 bit value. To achieve a comparable level of randomness, a password consisting of typable characters would have to be about 40 characters long consisting of completely random keypresses. If a person is ever in a position to actually get that master key value, you've already lost the data because before they can get to that key they have to:
-Get root privilges while the volume is mounted to get dmsetup table output, but if it's mounted they could just grab the data anyway.
-Get low-level physical access to your hardware to begin to crack the LUKS header of the partition or the content itself. If they are in a position to do so, they could/would image your entire volume and return your drive. In which case no matter what you do to the copy you got back (re-encrypt, change password, whatever), they can continue whatever crypto-analysis they want on their image of the data as it was when they first took it. You may be able to protect newly written data, but whatever risk of breaking the encryption on existing data is permanently there once imaging is possible.
-Get low-level access to your system and somewhere along the chain insert something to dump the key material to them once available. Again, once this is in play, it's already over no matter what you do, if they can dump that table, they can dump the data directly. In this case, let's assume one of those keyboard bugs slashdot had an article a while back was discovered by you in your system. Knowing that your passphrase is potentially compromised, with the key not based directly on the password, but just encrypted by the password, you can re-encrypt the key once the bug is removed and shred the old slot, and their keylog data becomes useless for the purposes of defeating your filesystem encryption. If the master key is essentially whatever you typed, you are significantly more hosed.
XML is like violence. If it doesn't solve the problem, use more.
Easy solution; don't keep stuff like movies in your home folder. I can't really imagine any reason why those would need to be encrypted, and as you discovered, doing so does carry a large performance penalty.
/Users/Shared/Music and ~/Movies and /Users/Shared/Movies; this keeps FileVault from encrypting my iTunes music library or my movie collection. It also means that on a multiuser system, other users can access the movies and music, without me having to enter my password or give them access to the rest of my files. (Actually I now have the movies and music on another drive.)
On my systems, I have symlinks set up between ~/Music and
If you do it this way, FileVault doesn't carry too huge a performance hit. It also has the advantage of allowing you to back up your documents in a secure fashion pretty easily: you log in as a different user, and just back up the File Vault sparseimage as a single file.
The "do you want to recover space" logout screen is fairly obnoxious, agreed; I hate it just because it stops the shutdown process with a dialog that requires human interaction. I wish it had some sort of a 30-second-countdown-to-default timer, so that if I hit "shutdown" and walk away, the process doesn't get hung up and just sit there, unsecured, forever.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
For anyone that wants to experiment with Debian, DM-Crypt and Luks, check out the howtos and/or the USB installer at http://feraga.com./
/boot encrypted for over a year and haven't had a issue. I'm sure its a little slower but dont notice it much.
I've been running lately from a USB Flash Drive (1GB) with everything but
This also allows you to leave a full installation with no private or incriminating data on the hard drive so if they ask to see the laptop......just let them.
The most incredibly useful application of this is sshfs, which basically lets you mount a remote machine as a filesystem without being root (as long as the FUSE kernel module is loaded). This has caused a huge productivity increase for me.
There is also an encrypted file system that runs under FUSE
http://arg0.net/users/vgough/encfs
So, you basically can have a big encrypted file lying around which you mount as a file system when you need it. The keys are encrypted in a separate control file, so there are no unencrypted keys lying around. You need both the pass phrase and the encrypted key file to mount the big file as an FS.
The reason to encrypt the whole drive as opposed to the writable sections is simply convenience - if you've got hardware assistance, it's probably designed to encrypt the whole disk using some crypto chip in the disk controller, and administratively simpler to use, and if you don't have that, it's probably easier to encrypt individual partitions or filesystems, or sometimes directories, rather than hack up some CPU-based driver that encrypts the whole disk.
From a performance standpoint, it's probably faster *not* to encrypt your program filesystems, and as far as encrypting swap goes, you took the big hit when you started to swap anyway, and rotational+seek latency is usually more of a limitation than overall throughput, so if this bothers you, but some more RAM. Encryption chips on the disk controller are probably faster than CPU software drivers, but not necessarily - your mileage is extremely variable.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Or for windows try Truecrypt (I think there is a linux version as well). It works like a dream, and there are some really niffty features (like addition of plausible deniability). It's pretty cool.
Har?