# Disk Encryption and performance

## josh

I was thinking of encrypting my HDs on my next Gentoo install. Does this have a significant impact on performance? I haven't been able to find a straight forward answer for this anywhere. It looks like on older machines (~PII) There would be a %50 reduction in disk throughput. Is it still a large overhead?

And to be more specific: I was thinking of leaving at least one partition unencrypted for music recording, since that is fairly disk-intensive. Could this still be hindered by the rest of the disks/partitions being encrypted?

----------

## pjp

Not sure if you've looked, but there is quite a bit of information in the DT&T forum.  Don't know if it provides an answer, but it might.  I've referenced 15 or so links to threads here for a start.  If you've already searched, nevermind.

Obviously there will be some impact, but security is about trade-offs.

----------

## josh

Thanks. Interesting reading. I guess that the gist of everything I've found is: There will always be a performance hit, not necessarily severe though. Depends on which out-weighs the other; security or performance.

It's got me thinking though, I guess for my purposes, I'd rather not take a performance hit at all. It was just something I wanted to toy with. I don't really keep anything on my computer that I wouldn't care if someone found out about after I died. Because for the average-home-desktop user, this is what encryption seems to be about right? Otherwise someone is probably not going to bother breaking into your home while you're away to remove your HD. If you do suspect that someone might do this, then maybe you do have something to keep secret. Probably the most secretive thing I keep on my computer is my checkbook-balance information. But anyone who breaks into my apartment could just as easily get the paper records as well.

----------

## groovin

i was thinking about doing an encrypted fs on my next laptop. my current lappy doesnt have the muscle to handle very much but i do use it for work and there are things in there that i wouldnt want anyone to see if it was ever stolen. stuff like emails, docs, spreadsheets, etc. nothing too critical, and i try to be careful, but who knows, there might be a cached web gui page with some sensitive stuff on it lurking someplace.

----------

## pjp

 *josh wrote:*   

> I'd rather not take a performance hit at all. It was just something I wanted to toy with.

 Maybe you'll find that it isn't very noticeable. 

 *josh wrote:*   

> I don't really keep anything on my computer that I wouldn't care if someone found out about after I died. Because for the average-home-desktop user, this is what encryption seems to be about right?

 After your dead, who cares?  I'd be more concerned about financial info, credit card #'s, bank #'s, etc.  Much more valuable to protect when I'm alive.

I haven't done it myself yet, but I try not to alter my running system too drastically.

 *josh wrote:*   

> Otherwise someone is probably not going to bother breaking into your home while you're away to remove your HD. If you do suspect that someone might do this, then maybe you do have something to keep secret. Probably the most secretive thing I keep on my computer is my checkbook-balance information. But anyone who breaks into my apartment could just as easily get the paper records as well.

 They may not steal the HD, but they might steal the whole computer.  As for the paper records, that's only likely if they're into ID theft -- the average Joe Burglar isn't likely to bother with paper, since they have no "street" value.  (At some point, I do plan to get a vault/filing cabinet.  I forget what they're called -- no, not a safe).

----------

## TheRAt

I have been researching keeping an encrypted partition, with the access key stored on a usb-stick, or some such external device..

The wthe speed of modern machines, even laptops, the biggest problem I have come accross out there seems to do with crashes and recovering from them.. From all material I have found on them, encrypted filesystems tend to make data recovery in case of failure rather painful.. This is one reason why I have kept away from doing this already on my laptop, as I tend to run it in ~x86 and although it is fairly stable now, in the sense that I have not had a crash in a long time, I have had issues with crashes at various stages of it's life over the past year or so.. Losing data always scares me a great deal... I guess I'll have to get in a habit of keeping encrypted backups of all the sensitive information..

Just my $0.02..

----------

## josh

pjp: more good points I've over looked. I guess it would be good to have so that if someone stole my computer merely for street value no one could get my bank records, etc. I guess it would be worth a try when i build a new system. See how the performance is. if its a problem then I would just redo it w/o encryption. One problem I know I'd have is that I know I'd be too lazy to remove the usb thumb-drive (with my enc key on it) from my computer. hence; it would always be with it.

----------

## pjp

I'd personally like to get a card/card reader system setup.  Assuming that a swipe could allow access to encrypted data of course (I assume it would).

----------

## ruben

I've been using an encrypted partition on an iBook G3 800Mhz, and at least i didn't notice any performance issues, but as i said, it was only an encrypted partition which contained my personal stuff, so the system and most of my homedir was not encrypted.  I've got an iBook G4 1.33Ghz now and i did a similar setup (using debian though). 

The reason i think encryption is important especially on a laptop, is mainly for in case it gets stolen.. the idea is that at least they won't have access to my personal stuff. Now.. why didn't i encrypt the whole home-directory?  Well..  i have some thoughts about that...  the first thought is that now, i mount the encrypted partition manually when i need it, and it uses a long passphrase.. it seems that if you encrypt your whole home-directory (and use pam) --as far as i've seen in howtos-- it's only protected with your normal login password, which is typically not a long passphrase (normally passwords on linux can only be 8 characters long, is that right?  i seem to remember that for some reason). So, my assumption is that it would be less safe?  The other thought i have... personally, i tend to leave my laptop in sleep mode instead of shutting it down. So, if someone steals it, they will have a laptop which has the encrypted partition mounted. That seems to me to make it easier to get to the data if they really want to... they 'only' need root access (or get through the xscreensaver lock). So, to me it seems safer to unmount the encrypted partition before sending it to sleep.. But though that is technically possible, the great thing of having a working sleep on your laptop is to avoid having to close all applications and open them again upon reboot... so it would be annoying to close your mail client, and unmount the encrypted partition before sending your laptop into sleep mode.

Your thoughts about this?  Should suspend-to-ram not be used when you want to benefit from having encrypted partitions?  Does suspend-to-disk ask/need the passphrase again on wake-up?

It's not like i'm really paranoid about people getting access to my data, but still, i don't want people to just get access to my personal data just like that when my laptop is stolen.

----------

## Gentist

I'm using encryption on my entire desktop system. The only partition that isn't encrypted is /boot, since I need access to the kernel for decryption.

As for overhead... There is a performance hit, but I can't normally tell unless I'm transferring large files. The system in question is an Athlon XP 1800+. Due to the high encryption used, the CPU usage tends to max out when I transfer files, leaving me with some 26MB/s as far as disk speed is concerned, IIRC. Should I mess up the system, I can access the disks from a LiveCD. Although that is a bit of a hassle, since I have to install and set up the encryption stuff without the disks. However, as long as I have my passphrase/key and the disks aren't damaged where the relevant encryption info is stored, I'm fine.

I wouldn't use encryption on a disk that is supposed to write/read large amounts of data. Encryption is really only good for storage. If you're going to dump, read or stream large amounts of data, such as raw video or audio, get a separate partition or hard drive that you leave unencrypted, and then move the data to an encrypted drive when it's time to store it.

The type of encryption I use only protects against one thing really; physical theft. And that's assuming that they don't steal it while it's powered on. If I unlock (decrypt) the drives, they're just the same as regular drives, plus the overhead, until I either #1 lock them, #2 unmount them, #3 power down the system. The third point more or less protects a desktop system, since it's rather hard to move it without powering it down. Laptops are trickier though. If you're going to encrypt the whole system on a laptop, you shouldn't really leave it on when you're not around (unless you're low on battery).

Concerning the suspend-to-disk. What does that do, exactly? Does it dump an image from the hard drive to RAM before the system boots, or after it loads the kernel? Or is it doing something else entirely? In either case, if it does load an image from the hard drive into RAM after it loads the kernel, then yes, provided that the image is stored on an encrypted partition, it should still require the password for the hard drive before allowing you access (otherwise it wouldn't be able to load the image, and the whole suspend-to-disk wouldn't work). I could be wrong though.

----------

## ruben

I just tested the suspend-to-disk. It's exactly the same behaviour as with suspend-to-ram. This is with the suspend-to-disk feature which is included in the vanilla kernels. On suspend, the kernel writes the data needed for resume to the swap partition. On booting again, it boots the kernel as normal, but at some point it checks the swap-partition and automatically resumes if it had been suspended before, then it recovers the data from the swap and when this is done, i have my desktop back. It didn't need a password (not even the xscreensaver password, presumably since i didn't leave it off long enough, but this can easily be fixed by locking the screen before the suspend).  I looked at the kernel sources and it has an option to encrypt the swap with a random key upon suspend, but this random key is saved unencrypted on disk and used to decrypt the swap upon resuming. Thus this is just to avoid having unencrypted data in the swap after a resume.

Hmm... it'd be nice to be able to give a passphrase to encrypt and decrypt upon suspend and resume, might be a bit annoying, but definitely safer.

----------

## tgh

While I haven't done encryption in Linux yet... I do use encryption on my Windows laptop.  There are a few ways (most of which can be used on the Linux side) that I protect my data.

1) Passwords and other text info: These are kept in plain text files in my home directory, but the contents of the files are encrypted using pgp/gpg.  (Make changes, copy to clipboard, encrypt clipboard, paste back into the text file and save.)  The big advantages:

- easy backups (you could backup to paper printouts if you wanted)

- information is always encrypted, except when I access it

- simple and easy (at least in Windows)

- you can encrypt the contents using multiple keys

- no special protection needed for the individual files (just the keyring)

2) Financial stuff (Quicken, scanned bank statements, receipts): These sorts of files are kept in a PGPDisk or other, mountable, encrypted file system.  The goal is to only mount the drive when needed and keep it unmounted the rest of the time.  

A bit more difficult to backup, but PGPDisk uses regular files to store the image, and it's easy to copy these files off to DVD/CD for historical snapshots or backups.  In fact, I make sure that my encrypted volume files are small enough to be dumped to CD/DVD.

3) File system encryption (EFS in Windows or loopback crypto in Linux):  Not as secure, but very convenient.  Secure enough to protect against most casual attackers (thief who steals the laptop but doesn't really care about the data).  My primary goal is that you can't just read the data right off the raw blocks of the disk, you have to do at least a little bit of work first.

In Windows, this is as easy as setting the "encrypt" flag on the file.  But if the machine crashes, you'll lose access to the files unless you backed up your keys (complicated procedure).  So machines where I use EFS, I make sure to take snapshots of the entire disk (using NTFSClone) so that I don't have to worry about losing the encryption keys.

...

In short, the more convenient the method, the less security.  So you may want to use a mix of methods (encrypted text files, temporarily mounted file systems, semi-permanent mounted file systems).

----------

## drumz

I've been using this technique http://www.linuxjournal.com/article/8599 for a while now.  I only mount my encrypted container when I need it, and even when mounted on my laptop I don't notice a performance degradation, but I'm also on a 1 year old laptop.

It's all tied into a usb thumb drive that has my key on it, which is autodetected at login to mount my container.   otherwise I just plug it in and enter a command.

----------

## Gentist

 *ruben wrote:*   

> Hmm... it'd be nice to be able to give a passphrase to encrypt and decrypt upon suspend and resume, might be a bit annoying, but definitely safer.

 

You may find this interesting. I'm not sure if you can adjust it to your needs, but it's worth checking out at least.

----------

## fcgreg

 *tgh wrote:*   

> While I haven't done encryption in Linux yet... I do use encryption on my Windows laptop.  There are a few ways (most of which can be used on the Linux side) that I protect my data.

 

FYI:  There is another option that has been available on Windows for some time, and is also available on Linux now.  The tool is "TrueCrypt", it is Open Source and free, and supports encrypted file containers and/or entire partition/disk encryption.  Furthermore, the partitions/file-containers are transportable between Windows and Linux (using vfat or NTFS filesystems).

The security architecture of the system appears VERY solid (although I haven't done my own thorough cryptanalysis of the system -- many others have).  File systems are properly filled with random and encrypted data, making it impossible to tell what (if any) data is stored within encrypted containers/partitions.  Keys protected via pass-phrases are allowed (of course), as well as one or more keyfiles used alone or in combination with pass-phrases.  Therefore, two-factor security over the encryption of the container is normal with TrueCrypt (e.g., keyfiles on a thumb-drive, plus a pass-phrase that you type in).  Finally, for those that need it, TrueCrypt allows "hidden" volumes to be created within a container, giving you so-called "plausible deniability"; e.g, even if you were forced/coerced to giving up your container encryption, the "hidden" container cannot be detected in any way.

Now that they have a Linux version available I've started using it too.

The Linux port of TrueCrypt isn't available in Portage yet.  A few of us have written some very clean ebuilds for it, all tests have passed (atm), and I expect that they will be entering Portage soon.  In the meantime, you can grab the ebuilds from here (Bugzilla) and throw them into your own Portage overlay.

TIP:  For the overlay, you'll need the "truecrypt-4.1 ebuild", the "truecrypt-4.1 Makefile patch", and the license file in your overlay "licenses/" directory, renamed to "truecrypt".  dm_crypt/dm_mod must also be enabled in your kernel, just as for other similar "container encryption" methods.

If you try it and have any issues/questions, please post back to Bugzilla.

 *tgh wrote:*   

> In Windows, this is as easy as setting the "encrypt" flag on the file.

 

I strongly suggest you don't use this option anymore.  The built-in encryption in Windows XP is entirely broken from a cryptology point of view.  The security of the system is only as strong as its weakest link, which in Windows XP's case is a merely obfuscated key stored on the filesystem.   :Shocked:   A little bit of legwork is required to grab key information from the right places, and you've got 100% access to the file/directory/etc.

 *drumz wrote:*   

> I've been using this technique http://www.linuxjournal.com/article/8599 for a while now.  I only mount my encrypted container when I need it ... It's all tied into a usb thumb drive that has my key on it ...

 

I've found the TrueCrypt solution to be more simple than that method, while providing better security in many ways.  For example, the article gives some ambiguity regarding container padding with zeros instead of /dev/random.  However, such a decision is CRITICAL to defend against information leaks and related attacks.

If you really want to get into this stuff, take a look at the TrueCrypt site.  They have extensive FAQ's, a large PDF manual, and detailed architecture documentation regarding cryptology and their implementation.

----------

## ruben

The best security seems indeed to be to use a container which is only mounted during the time you need the data.  But still, if you want to be really secure... it seems you also need to encrypt the whole home directory, since it seems inevitable to avoid leaking some data out of the container. I mean for example file names in a "recent documents" list, thumbnails which are cached, or ~/.bash_history, or files which are for some reason copied to /tmp... In any case, for my own use, having the whole home directory encrypted is gonna be safer than only using the container partition.

About using a long key on an usb drive: personally, i don't find that very attractive, because if you lose the key, you also lose your data. Someone could steal your usb drive, just for the drive, for example. And of course, it's more hassle. Although it might be less safe, i prefer a good long passphrase. Of course, this is also in the context of my own laptop. I don't have any data that is actually worth a lot of effort to get it. I mean, it's not like someone is going to steal my laptop for the data, but if someone would steal it, they would probably look around on the disk to see whether they can find something interesting. In that regard, it's not a nice thought they could read a lot of personal stuff just like that.

The only thing i can think of to solve the problem when someone steals the laptop while it's in sleep mode, is to run a daemon, which would simply shutdown the laptop if it doesn't get a key or something within 3 minutes after wakeup for example.

----------

## fcgreg

All good points.  I wasn't trying to negate the usefulness of encrypting large directory structures or an entire partition -- that definitely has its merits.  I just wanted to present a better (IMO) way of doing cross-platform container encryption to the thread ("better" meaning when compared to existing, usually difficult-to-implement cryptoloop or "home-grown" dm_crypt solutions).

My apologies to the O.P. for pulling this off-topic.  However, I want to respond to a few of your points.

 *ruben wrote:*   

> ... if you want to be really secure... it seems you also need to encrypt the whole home directory, since it seems inevitable to avoid leaking some data out of the container. I mean for example file names in a "recent documents" list, thumbnails which are cached, or ~/.bash_history, or files which are for some reason copied to /tmp...

 

This is absolutely a good point; one that I wasn't trying to address.  A suggestion I fully support is making one's entire home directory an encrypted container.  This is generally better than making "/home" a separate partition and encrypting that, as it is easier to do offline backups and gives you the means to isolate each user's home directory into a separate container, if desired.

 *ruben wrote:*   

> About using a long key on an usb drive: personally, i don't find that very attractive, because if you lose the key, you also lose your data. Someone could steal your usb drive, just for the drive, for example. ... Although it might be less safe, i prefer a good long passphrase.

 

Re: losing the key:  Of course, you'd want this backed-up somewhere, usually off-line at home, encrypted on a CD you carry with you, etc.

Re: the passphrase:  Passphrases are fine as long as they are good/secure, as you point out.  However, they are still susceptible to interception/keystroke logging.

That's why with a system like TrueCrypt (and others) that make this seamless with minimal effort, you can easily use both if desired.  This is where the "two-factor" security comes into place:

1) Something you know (passphrase)

2) Something you have (key file)

 *ruben wrote:*   

> ... but if someone would steal it, they would probably look around on the disk to see whether they can find something interesting.

 

Very true.  For most of us, if data isn't casually available to a would-be thief, that is sufficient protection -- for now.  Unfortunately, each year it becomes more and more profitable for knowledgeable information thieves to harvest data, especially from laptops which are both more prevalent and often contain sensitive personal or business data.

Anyway, good discussion and thoughts... thanks..

----------

## Hypersniper

 *fcgreg wrote:*   

> 
> 
> Re: the passphrase:  Passphrases are fine as long as they are good/secure, as you point out.  However, they are still susceptible to interception/keystroke logging.
> 
> 

 

Well, so is anything else; catching read access to key files is even easier than keylogging. If you're working on a compromised machine, there's no chance for 100% security.   :Mad: 

----------

## fcgreg

 *Hypersniper wrote:*   

>  *fcgreg wrote:*   
> 
> Re: the passphrase:  Passphrases are fine as long as they are good/secure, as you point out.  However, they are still susceptible to interception/keystroke logging.
> 
>  
> ...

 

I disagree.  Capturing keyfiles requires that one of the two following scenarios are true:

 You are already capturing all file data being read on the compromised machine (almost never done and extremely unfeasible in most circumstances).

  .. OR ..

 You have already compromised and analyzed the machine in question, are aware of the use of keyfiles for secured data, and have taken steps to specifically capture the data when it's used.  This attack is more feasible in some ways, as the amount of data you're capturing is easier to manage and store.  However, much more up-front analysis of the machine is required, all the while risking that the target will realize their machine has been compromised and close your access.

In any case, I think you'd be hard-pressed to prove your assertion that catching the file-reads is "even easier than keylogging" -- especially when keystroke-logging can be done by any run-of-the-mill script-kiddie trojan downloaded through a Web site out there.

Furthermore, your statement refutes a point I was not even trying to make.  I never said that using keyfiles and/or passphrases alone gave you "100% security", as you say.  I said that using the two together gives you "two-factor security", which greatly increases the protection of your data, even if the machine itself is compromised.

----------

## drumz

This thread has been really informative.  It's really nice when people can intelligently post their facts/opinions without taking personal offense or attacking other posters.  Threads like these help the community by not only telling future searchers about different technologies that may be available but also some of the other side issues they need to keep in mind.

Anyhow.....

What it really boils down to is a few things:

1.  Knowing what techniques are currently available at the time you implement something.  As others have posted after my post, there are now several new projects supporting encrypting things to different degrees.  Unfortunately when I started implementing something years ago (and then wrote about it later in the article) some of these nice new projects didn't exist or hadn't existed long enough in order to 'prove' that they were going to stick around long enough.  If I were to do it again I would do some things differently, and some things I would do the same.

2.  Knowing the pluses and minuses of each option so you can intelligently decide which one is right for YOUR situation.  That's the great thing about linux and Gentoo.  There are many ways to do the same thing, and you're likely to find something that will fit the bill perfectly and that you'll understand.  In my case I just wanted to protect my personal systems from theft.  The average thief isn't going to bother hassling with encrypted data - providing they can even spell linux much less figure out that a file is encrypted and not a binary file.

3.  Weighing the amount of risk you are willing to take, which is really what security boils down to.  For MY personal, home use the system I developed balances the amount of security I need with a reasonable amount of inconvenience to reach a level of security that I want.  If I were to do this type of system for work, it would be much different because the needs/requirements are much different there.

----------

## fcgreg

Thanks for the posts drumz, and again, I also give my thanks to everyone for the enjoyable discussion.  A few more thoughts...

 *drumz wrote:*   

> ... Knowing the pluses and minuses of each option so you can intelligently decide which one is right for YOUR situation.  ...  In my case I just wanted to protect my personal systems from theft.  The average thief isn't going to bother hassling with encrypted data - providing they can even spell linux much less figure out that a file is encrypted and not a binary file.

 

Yes, a good point.  I wholeheartedly agree that the solution should fit the need.  In your case it sounds like you're well covered.

However, I'm also excited about making the very advanced solutions as easy to implement/use as the "simple" ones.  If the divide between security and convenience can be reduced, then more users can share the benefits of robust security with minimal (or zero) additional effort.  I think the industry at-large is well on its way to accomplishing this goal.  Applications like dm-crypt, TrueCrypt, FreeOTFE, GnuPG, and many other programs seem to indicate this trend.

Regards...

----------

