Slashdot Log In
How To, When You Have To Encrypt Absolutely Everything?
Posted by
ScuttleMonkey
on Mon Feb 09, 2009 01:17 PM
from the first-step-is-teaching-people-how-not-to-be-stupid dept.
from the first-step-is-teaching-people-how-not-to-be-stupid dept.
Dark Neuron writes "My institution has thousands of computers, and is looking at starting an IT policy to encrypt everything, all hard drives, including desktops, laptops, external hard drives, USB flash drives, etc. I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives, but I am concerned about overhead and speed penalties. Does anyone have experience and/or advice with encrypting every single device in a similar situation?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...
I think you're going to find most people advising you to choose TrueCrypt [truecrypt.org] which boasts:
I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking [truecrypt.org] the various encryption algorithms it offers.
... but i am concerned about overhead and speed penalties.
Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option [slashdot.org] which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.
... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.
I wouldn't recommend waiting that long, however.
Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.
I do not know for certain but I do not believe there is a painless push-across-the-network way to do this
TrueCrypt (Score:5, Insightful)
You want TrueCrypt.
It's probably better than a hardware solution. They keep screwing up and snake-oiling the hardware ones, but you can audit TrueCrypt (and people have), and pre-boot authenticated system drive encryption is pretty much what you want.
As for speed... I don't know what you're worried about. AES-256-XTS (best-in-breed, the new standard, which TrueCrypt pioneered and uses) runs at over 150MB/sec in benchmark, and that's on one core. Your hard disk very probably doesn't run that fast.
All our machines are encrypted using similar means, and we've never experienced any problems with performance.
PGP's Whole Disk Encryption isn't as good - that kept stalling in kernel mode under XP, causing hiccups on lots of disk accesses; and eventually the driver bluescreened on every boot and there was absolutely no way we could get it back, which lost us terabytes of data... but TrueCrypt has caused us no such problems, and costs nothing. (If it worked with the leftover eTokens from our earlier PGP deployment, it'd be perfect.)
Parent
Re:TrueCrypt (Score:5, Interesting)
Parent
Re:TrueCrypt (Score:5, Informative)
Nobody deals with that, for the moment. I don't think the hardware solutions deal with that for every case, either.
I've heard of some possible solutions being thrown out there - including a CPU "disabled cache"-type software solutions - but there's nothing being sold yet.
Parent
Re:TrueCrypt (Score:4, Interesting)
Parent
Re:TrueCrypt (Score:4, Insightful)
Is the common approach simply to pop up a password-protected screensaver?
You should be doing that anyway. Defence in depth and all that.
Everyone seems to hail TrueCrypt (or any other full disk encryption) as the second coming but, like any other security mechanism, it should not be your only. So yes, pop up a password-protected screen saver - a cooler feature would be if TrueCrypt "hooked" into said screen saver and destroyed keys/dismounted volumes on two or three false passwords.
Parent
Re:TrueCrypt (Score:5, Informative)
TrueCrypt has several options. The way I have it configured, the TC volume is automatically unmounted when I suspend, and I need to re-mount it when the notebook wakes back.
I understand the password is not in RAM anymore after a suspend. These are the options I use:
"SaveVolumeHistory" = 0
"CachePasswords" = 0
"WipePasswordCacheOnExit" = 1
"WipeCacheOnAutoDismount" = 1
"StartOnLogon" = 0
"MountDevicesOnLogon" = 0
"MountFavoritesOnLogon" = 0
"DismountOnLogOff" = 1
"DismountOnPowerSaving" = 1
"DismountOnScreenSaver" = 0
"ForceAutoDismount" = 1
Parent
Re:TrueCrypt (Score:4, Informative)
You are misunderstanding the problem. Defending data in a datacenter is a completely different problem that data-at-rest encryption really doesn't help you with.
In most states, whenever a client computer could contain personally-identifying data, data breaches must be exposed to any potential victim and the general public.
In some cases, that includes things like browser caches, and other temporary files. So most financial institutions and government agencies opt to encrypt all mobile devices. Some law enforcement agencies encrypt desktop computers as well.
Encryption is very easy to do. Key management is hard. Truecrypt is great for an individual user, but falls down when you have to manage a non-trivial number of clients.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Insightful)
6.1a won't even install on my Inspiron 9400, giving me a "memory parity error" on the initial reboot test for full drive encryption.
Have you run memtest86+ [memtest.org] and let it go for at least two full tests? Could be one of your sticks is bad.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
The post you reply to is written by a numbskull. Compiling software doesn't even begin to ensure that all possible memory locations accessed and bit values are written. The vast majority of what is going on during a compile and/or md5 sum is going to happen in the processor's L1 & L2 caches.
On the other hand memtest86(+) has a methodology that includes disabling cache and ensures that all possible locations are written to and read from. Additionally there is a mixture of patterns used, from random patterns for general testing to specific patterns (both bit value & access ordering) for exercising known failure modes of DRAM.
Finally the idea that you can "stress" you RAM is nuts. Outside of running the device out of spec (e.g. overclocking), the only "stress" possible is heat and just being on will get it into the normal operating temperatures. Anything else is what it's designed to do, there is no ubermagic access pattern driven by that "well known" gcc that causes DRAM to fall over dead.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Interesting)
In addition, the TrueCrypt user community lately is getting the shaft from the "TrueCrypt Foundation".
Case in point, if you visit their forums, starting about 6 months ago, around the time of release of v6, the forum administrators now delete anything "critical" of TrueCrypt. Basically, your only allowed to discuss the positives of the software, or problems with the intended operation of it. Any "bugs" or "weaknesses" mentioned result in having the thread either locked, more than likely deleted, and if you push an issue, open a second thread on a 'deleted thread' your likely to have your account locked.
5.1a was the last version released before this new policy of "only positives". Not to mention that the forums are already so heavily locked down (No public email addresses to register accounts, no private messages on the board, no threads that are not 'on topic'). Some of us tried (semi-successfully) to have frequent contributors meet over on Wilder's Security forums. (http://www.wilderssecurity.com/) Difficult though since they started deleting our postings since they weren't on topic, and private messages are impossible.
Sadly, as a result of this, I used to heavily endorse TrueCrypt, but I can no longer stand behind them until they let the community get re-involved, for the good and the bad.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
Yes, and as the OP was asking for "real-life" benchmarks, here they are. Tom's Hardware benchmarked TrueCrypt thoroughly and found practically no overhead.
http://www.tomshardware.com/reviews/truecrypt-security-hdd,2125.html [tomshardware.com]
Parent
TrueCrypt is very fast (Score:4, Informative)
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:4, Informative)
We use truecrypt for full drive encryption. So far we have encrypted well over 100 notebooks without issue. The full drive encryption has very little overhead and besides a password at start up most users don't even notice.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:4, Insightful)
When people check data out though, it has to get stored somewhere. That somewhere might be a local disk, or a USB stick, etc. So those places need to be encrypted if you want to protect against lost/theft.
Your server can be sufficiently protected (physically and virtually) that it does not need the drives encrypted - encryption does not protect against over-the-wire attacks anyways. While it is probably unreasonable to protect EVERY pc from being stolen, it is not unreasonable to protect servers from being stolen - eg, an alarm that goes off way before anyone gets near the server room. 24/7 guards, if you can afford it, etc.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
You can encrypt your key with a password (I'm sure truecrypt supports this) but then you might as well just have used a password in the first place instead of encryption.
WTF? If someone steals a computer and puts a drive in another computer the windows/BIOS password won't do shit, encryption will.
What you do is store sensitive material on secure servers and have people check out copies of material that they have access to. I'm sure keeping sensitive data off local hard drives would be easier than actually protecting all those hard drives.
No it won't. If they need to use the data then it will be cached on their computer whether it is stored centrally or not. And if they weren't using the data then it wouldn't have been on the computer to begin with. Centralization will only help if you move from thick-client to a thin-client-like processing of data. That will limit the amount of distribution of sensitive manner - "checking data out" won't.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
I'm not so sure about that. The deal with whole disk encryption is that it's fail-safe; it doesn't matter if something bad happens, the data is stored in a secure state by default. A check-out model doesn't give you that.
Also, speaking from experience, it's incredibly difficult to get end users to even understand what sensitive data is, much less train them how to work with it in a secure manner. Any security model that relies upon educated (and diligent) users is probably going to fail sooner rather than later.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Funny)
Coming from an Org that encrypts everything
Tom Cruise? Is that you?
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
If the pagefile is located on the encrypted volume, not much harm, might make cryptanalysis easier if someone can get two images of your drive at different times.
If the pagefile is not on the encrypted volume, then it is leaving chunks of no-longer-secure data for anyone to see.
Parent
Re:TrueCrypt or Wait for On Drive Upgrades (Score:5, Informative)
A simple perusal of their website reveals:
Q: We use TrueCrypt in a corporate/enterprise environment. Is there a way for an administrator to reset a volume password or pre-boot authentication password when a user forgets it (or loses a keyfile)?
A: Yes. Note that there is no "back door" implemented in TrueCrypt. However, there is a way to "reset" volume passwords/keyfiles and pre-boot authentication passwords. After you create a volume, back up its header to a file (select Tools -> Backup Volume Header) before you allow a non-admin user to use the volume. Note that the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. Then ask the user to choose a password, and set it for him/her (Volumes -> Change Volume Password); or generate a user keyfile for him/her. Then you can allow the user to use the volume and to change the password/keyfiles without your assistance/permission. In case he/she forgets his/her password or loses his/her keyfile, you can "reset" the volume password/keyfiles to your original admin password/keyfiles by restoring the volume header from the backup file (Tools -> Restore Volume Header).
Similarly, you can reset a pre-boot authentication password. To create a backup of the master key data (that will be stored on a TrueCrypt Rescue Disk and encrypted with your administrator password), select 'System' > 'Create Rescue Disk'. To set a user pre-boot authentication password, select 'System' > 'Change Password'. To restore your administrator password, boot the TrueCrypt Rescue Disk, select 'Repair Options' > 'Restore key data' and enter your administrator password. /noisocheck).
Note: It is not required to burn each TrueCrypt Rescue Disk ISO image to a CD/DVD. You can maintain a central repository of ISO images for all workstations (rather than a repository of CDs/DVDs). For more information see the section Command Line Usage (option
Seriously, a little research isn't hard.
Parent
Hard Drive Encryption - Theory vs. Reality (Score:4, Funny)
Let me explain to you how this works. In pictures:
http://xkcd.com/538/ [xkcd.com]
Re:Hard Drive Encryption - Theory vs. Reality (Score:5, Funny)
Of course, if you're using Truecrypt, they won't know when to stop hitting you.
Parent
Re:Hard Drive Encryption - Theory vs. Reality (Score:4, Insightful)
Oh. Well THAT sounds like a plus.
Parent
Re:Hard Drive Encryption - Theory vs. Reality (Score:5, Funny)
Yeah...
Encryption will save your and your institution versus legal attacks, but if others' "people" may talk to your "people" with a wrench, then only iron will can save you.
Even biometrics can be fooled (e.g., eyeballs and fingers aren't that hard to remove these days).
Parent
Theory vs. Reality - Seriously (Score:5, Insightful)
That comic has been making the rounds. It's cute, but not applicable.
If the submitter is in an organization with thousands of machines, the notion that any user will be required to keep their password confidential in the face of torture is laughable. That's for specially trained operatives, soldiers, and other assorted heroes. Those of us in the normal world will probably adopt a more rationale perspective. If someone were crazy enough to steal one of our laptops, simultaneously snatch the user, and threaten them with torture, our folks know to give up all passwords, immediately. We're only required to keep data confidential where it is reasonable to do so. When floods sweep away your car, wave goodbye to your laptop in the trunk. When someone threatens you physically, tell 'em what they want to hear.
Our people are more important than our data. Our people are more important than the publics data. If we lose a chunk of data, we have ways to reconstruct what was lost and mitigate damage. If we lose an employee, there is no way to achieve a good outcome.
Reasonable?
Parent
Re:Theory vs. Reality - Seriously (Score:5, Insightful)
Thank you.
Many more years ago than I'd care to discuss, I used to pull graveyards at the local 7-11. Corporate and Franchise policy back then was, that if you were robbed, you gave up the entire store, on the theory that you were more valuable than the cash or store contents.
I know it was probably a CYA to avoid lawsuits from clerks, but it was still a sensible and sane policy.
Parent
You're still missing the point. (Score:5, Informative)
Hard drive encryption isn't meant to protect against social engineering attacks. It's meant to protect against attacks that don't require social engineering, like stealing or cloning a database server's drives for the information. More than anything, it's meant to provide reasonable assurance that if one of your employees' computers gets stolen by a common thief who just wants to sell it for the cash value, somebody else down the line won't be able to read the data in the drive and take advantage of it.
Parent
Re:Theory vs. Reality - Seriously (Score:5, Informative)
There's a huge difference. When you see numbers like "128-bit," you're dealing with a symmetric encryption algorithm (e.g., AES). When you see numbers like "4096-bit," you're dealing with an asymmetric algorithm (e.g., RSA).
See the NIST Recommendation for Key Management (PDF) [nist.gov], page 63. For example, to get RSA that is "equivalently" secure (for some predicted meaning of equivalent) to AES-128, you need a 3072-bit key. The table is explained on page 62.
As an aside, the comparably small key sizes that asymmetric elliptic curve cryptograph (ECC) can use, illustrated on page 63, are one of the reasons that ECC is so valuable.
Parent
Re:Hard Drive Encryption - Theory vs. Reality (Score:5, Insightful)
No. Let me explain to you how this works, with a story link [slashdot.org].
Companies are storing more, and more, and more, and more, and more information. About their customers, about their suppliers, about themselves, about employees, about employees friends, about customers friends, about customers employees, etc , etc, etc. It's like a Panopticon Party, and everyone with a datacentre is invited. With hard disc space costs plummeting, processor power rising, and networked recorders becoming ubiquitous, companies and managers everywhere have succumbed to the data deluge, and have meticulously stored and categorized every last bit they can lay their hands on. (For what purpose is a question for another day).
The result. Exabytes of data sitting idle on servers, unencrypted, waiting to to stolen. Predictably it is, usually with nothing more than a USB key, or USB hard disc. The people who pay for such illicit data presumably want it all for something. If the data was even encrypted in the most basic fashion, most of the constant data breaches we here about would never have occurred.
Companies have two options. First, stop gathering and storing this data. That will never happen. Most compaines are data junkies by this point. Secondly; Encrypt, Everything. Everything. Any unencrypted portion of your network is a data breach waiting to happen. Even the slightest crack is a PR disaster waiting to happen. I don't care if its a telnet client on a headless offline BSD system, sitting in a securely locked room in the basement. Someone WILL find a way to lose data using it.
I applaud the submitters goal. It is a worthy one, and is likely the only real thing standing between your credit card number and a fraudsters ebay login page. More power to them.
Parent
Yeah... (Score:3, Insightful)
A subtle balance between encrypting most essentials and leaving non-essentials unencrypted. For example, you may want to only encrypt parts of your hard disk as encrypting the whole disk will impact performance.
Also, watch how external USB keys are encrypted. if you deal with clients and offer loaner machines, their USB drives could become encrypted and useless when they return to their own office.
I'm all for encrypting, however hopefully the higher ups also consider the potential performance hits and liability issues.
Re:Yeah... (Score:5, Informative)
Parent
Re:Yeah... (Score:5, Interesting)
you may want to only encrypt parts of your hard disk as encrypting the whole disk will impact performance.
Yeah, but if you're running Windows, be sure to get the swap file (depending on security concerns, maybe having Win zero the swap file at shutdown might be enough) and all that crap in Documents and Settings. If concerns run to file/folder names, don't forget the MRU lists. I do have a Truecrypt partition, but regularly find bits and pieces of stuff scattered here and there on C: unencrypted.
Win does not segregate data in a helpful fashion. If my security concerns were serious, I wouldn't dare anything less than whole disk encryption. Actually, I'd probably stop using Windows.
Parent
Re:Yeah... (Score:5, Interesting)
How about the following...
"My presentation is on this drive and I forgot the password, get my files for me!"
users dont like it when you say, " sorry, but unless you remember your password all your files on that drive are gone forever."
That stopped it at my last IT gig, I mentioned that response to the CTO and he said...
"oooh, Did not think of that. let's skip encryption."
Parent
Re:Yeah... (Score:4, Interesting)
If it's corporate, just make them encrypt it using their key and a corporate master key. Then you can decrypt it using the master key if some boneheaded user loses their key. You should do this anyway to prevent some user from walking with all of their data, and to maintain SoX compliance.
Obviously this will increase the overhead, but frankly, encryption should be used sparingly anyway.
Parent
Re:Yeah... (Score:5, Informative)
I can't tell, are you joking? With all the sarcasm around Slashdot it's sometimes difficult to tell if someone is being snarky.
The scenario you mention wouldn't happen unless a half-baked encryption scheme was used. HP, RSA, IBM, and even Truecrypt all have recovery options ranging in levels of difficulty to implement. RSA's key management tools are quite handy but you definitely pay a premium for them. HP's are clunky like all HP software, IBM has been doing it for years but again you pay and arm and a leg.
With Truecrypt you create two to three thumbdrives when you do the initial encryption, two of them store the master encryption key and the third has whatever key is needed for authentication depending on how you want to deploy it. The only fault I have with Truecrypt is that there are a dozen ways to deploy it so you have to read and plan very carefully before deploying it on any level.
Once you have your flash disk you copy its contents to an encrypted folder on your SAN somewhere and keep the flash drive in a properly fire-proof safe. One flash drive has the keys for over a hundred machines with room for plenty more, keeping two copies ensures that a flash drive dying won't leave your data inaccessible during transport to the server and should the SAN experience some sort of data loss you can go back to the flash drive to recover keys.
Encryption is pretty scary as your keys are extremely important as you mention, once the key is lost then so is the data. So you take a few precautions ahead of time and then you don't need to worry.
Parent
Re:Yeah... (Score:5, Insightful)
users dont like it when you say, " sorry, but unless you remember your password all your files on that drive are gone forever."
That stopped it at my last IT gig, I mentioned that response to the CTO and he said...
"oooh, Did not think of that. let's skip encryption."
There's exactly two WTFs here, you and the CTO. We have full disk encryption, but there's a support procedure to identify and get a password reset code. And if all else fails, IT has an extra master login to decode the disk. I don't know what truecrypt has but even a cursory look at the available products would have told you that. No sane business would ever work so that if an employee got run over by the bus, everything that person has been doing is gone forever.
Parent
Dont. (Score:5, Insightful)
I've seen this, too (Score:4, Interesting)
Given how glacially slow IT moves in a university -- and how much buy-in the prima donnas demand for even the slightest decisions -- I'm sure the password topic is still brought up at the weekly meeting.
Security only works if the convenience/security ratio is balanced properly for the environment at hand. At a public university which is used to openness, the "encrypt everything" just wouldn't fly (because that one tenured prof who likes to share and then remote mount his entire C: drive between his office and home over an unencrypted network connection would pitch a fit and kill that plan by fiat). If you work at a security company or bank or the NSA, then I'd suspect you'd have an easier time of it.
-B
Parent
Key Management? (Score:5, Insightful)
What's your key management strategy?
Re:Key Management? (Score:5, Funny)
To empower individuals to utilize synergistic approaches to achieve goals and exceed expectations. :)
Parent
TrueCrypt and Mac (Score:4, Informative)
TrueCrypt does not support Pre-boot full disk encryption on the Mac. Only product I know of that does that right now is PGP Whole disk (latest version).
Just don't do it. (Score:5, Insightful)
I see this all the time and it always makes me cringe.
If you treat all data the same, it is impossible to convince users to treat any data differently from any other, and they will all default to "Sloppy", and you won't care because you'll be certain that the encryption is going to save your ass.
It is a much much better idea to have a very distinct line between secure and insecure, so that people have that distinction hammered into their heads every time they touch secure data. Otherwise, someone is going to get sloppy with their private key, and you're going to get exploited and never see it coming.
ROT 26 (Score:5, Funny)
Tell the suits you are implementing state-of-the art ROT-26 encryption on everything. Take a month off. Come back, pronounce it complete, and ask for a raise.
Re:ROT 26 (Score:4, Funny)
I suggest obfuscating it slightly, pardon the 'irregularities' of my math
ROT-26 Swap 2*13 for 26.
ROT-(2*13) Swap Triskadeca for 13
ROT-(2*Triskadeca) Swap Duplo for 2*
ROT-Duplotriskadeca Add Duplotriskadeca to both sides
ROT = Duplotriskadeca Eliminate
0 = Dupliskadeca Let d = 4; add 1 to each side
1 + 0 = Dupliska(4 + 1)eca = Dupliskaeeca Reorder
1 = cakeisadupel We know that l looks like 1, so go ahead and eliminate.
0 = cake is a dupe
The cake statement is a false, a lie!
Hence we can call this DoublePortal encryption, while knowing we maintained mathematical purity for the name.
Use of this naming convention for ROT(26) will surely be more amenable to the PHBs.
Parent
"I don't know where my sensitive data is!" (Score:5, Insightful)
I see this directive a lot. It boils down to "We don't know where our sensitive data is, or don't trust our employees to keep it where it should be, so we're encrypting everything!".
Most of the time when I see this, it's because the person making the directive is responsible for security in some manner but has no experience with risk management and mitigation, so they go for the "all out, definitely safe!" shotgun solution. The problem is there's no such thing!
What risks are you actually attempting to mitigate through encrypting everything, and are you aware of the risks you are creating? These are questions the person who made the directive should be able to answer! For instance, if you are trying to mitigate the "PII/Lost Laptop" risk, why not implement drive encryption on laptops only, and buy USB sticks (such as Ironkey) which guarantee the encryption? If you're trying to stop a malicious insider, no amount of encryption will save you if they've been given the key.
Finally as others suggested, what's your key management and password management strategy? I -love- truecrypt but I wouldn't suggest it for a whole enterprise without being able to answer the question "How do I recover the key to this workstation when the employee dies unexpectedly of a heart attack?".
Best of luck in your endeavor but remember this rule: When it comes to implementing security, NEVER BE AFRAID TO ASK MORE QUESTIONS - especially about requirements.
Don't worry about performance. (Score:5, Insightful)
My company has been running all the machines that aren't at our data center encrypted, starting around August of 2007. On my laptop I honestly just have not noticed the overhead of encryption more than once or twice in that time. When I started it was on a 1.8GHz Pentium M box, so it's even less of a concern with my 2.5GHz Core 2 Duo.
As I said, it's worked out so well that it's now the standard setup on our laptops. The Eee's my wife and I got last week are running encrypted partitions as well.
Before I started, I was worried about the overhead of the encryption, but I was really worried for no reason. I've almost never noticed it, and none of the other folks in my organization complain about it either.
We are using the Linux encryption stuff running under LVM, so our swap is encrypted as well. Everything but /boot is encrypted. We are using "cryptsetup" (dm_crypt) (built into the Ubuntu Hardy and up "alt" installer and Fedora 10 and up). I'd recommend that for the Linux side.
I've heard good things about TruCrypt, but haven't used it. We don't use Windows or Mac, so the stuff that's built into Linux is our preference.
The dm_crypt stuff includes "LUKS", which allows you to have multiple keys for accessing the data. So you'd probably want to set up a "user key" and "company key" for each system, and if the user forgets their key someone can check out the company key and set a new user key.
So, in that way you don't need to worry about the user forgetting their password.
Also, you still need to have good backups of the file-systems, so if someone does forget their data you can at worst case recover from the most recent backup.
So the worry of losing keys is a no-op. If you don't have good backups, check out backuppc. I've been very impressed with it.
Finally, as far as the other poster saying that it's a "shotgun" approach for people who are too lazy to identify their important data... Do you also try to back up only your most important data? What if someone adds a new important data?
I started with only encrypting a part of the system (because full system encryption was difficult to achieve in older Linux releases). The problem is with leakage. As with backups, it's more provably correct to cover more data rather than less.
This is why for backups I only do exclusions instead of listing the data I want to back up. That way if more data gets added, I have to explicitly exclude it for it not to be backed up.
The same thing applies to crypto. Ok, so you encrypt your sensitive data. Do you have updatedb running? Or beagle? If someone looks at the "locate" database of all the files on your system, will that expose something you didn't want exposed? Like the list of your clients? It would for ours, because our document repository has useful file-names. Similar for the beagle database.
What are you leaking that you didn't intend to be?
Just encrypt the whole damn thing.
Sean
Re:Key Management (Score:5, Funny)
Parent
Re:Have fun with management (Score:5, Funny)
There aren't any tools that manage them centrally and allow for compliance and auditing.
Crap. Has anyone told Google yet? Best get them to switch to Windows quickly!
Parent
PLAESE BACK UP FRIST!!! (Score:5, Funny)
Parent