Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Encryption Security

How To, When You Have To Encrypt Absolutely Everything? 468

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?"
This discussion has been archived. No new comments can be posted.

How To, When You Have To Encrypt Absolutely Everything?

Comments Filter:
  • by eldavojohn ( 898314 ) * <eldavojohn AT gmail DOT com> on Monday February 09, 2009 @02:18PM (#26786803) Journal

    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 [] which boasts:

    • Creates a virtual encrypted disk within a file and mounts it as a real disk.
    • Encrypts an entire partition or storage device such as USB flash drive or hard drive.
    • Encrypts a partition or drive where Windows is installed (pre-boot authentication []).
    • Encryption is automatic, real-time (on-the-fly) and transparent [].
    • Provides two levels of plausible deniability [] , in case an adversary forces you to reveal the password: 1) Hidden volume [] (steganography) and hidden operating system [] . 2) No TrueCrypt volume can be identified (volumes cannot be distinguished from random data).

    I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking [] 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 [] 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 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 ... 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.

    • TrueCrypt (Score:5, Insightful)

      by Anonymous Coward on Monday February 09, 2009 @02:32PM (#26787085)

      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.)

      • Re:TrueCrypt (Score:5, Interesting)

        by timeOday ( 582209 ) on Monday February 09, 2009 @03:59PM (#26788775)
        My problem with TrueCrypt - and all software solutions - is how do they handle suspending a laptop to RAM? Apparently the keys are not overwritten in RAM until you unmount the partition, which means closing down all applications that access the sensitive data. I couldn't live with that. Instead the apps should be suspended, the encryption keys overwritten, and the apps not resumed until after the user inputs the password upon resume.
        • Re:TrueCrypt (Score:5, Informative)

          by Panaflex ( 13191 ) <convivialdingo AT yahoo DOT com> on Monday February 09, 2009 @04:20PM (#26789127)

          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.

          • Re:TrueCrypt (Score:4, Interesting)

            by timeOday ( 582209 ) on Monday February 09, 2009 @05:33PM (#26790221)
            So how does TrueCrypt handle laptop suspend? Being a software solution, it wouldn't even necessarily know the laptop had been suspended, correct? It might seem a minor point, but when/if I lose a laptop, there's a strong probability it will be suspended to RAM at the time. Is the common approach simply to pop up a password-protected screensaver?
            • Re:TrueCrypt (Score:4, Insightful)

              by Architect_sasyr ( 938685 ) on Monday February 09, 2009 @06:39PM (#26791255)

              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.

        • Re:TrueCrypt (Score:5, Informative)

          by rduke15 ( 721841 ) < minus berry> on Monday February 09, 2009 @06:09PM (#26790821)

          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

        • Re: (Score:3, Insightful)

          by wvmarle ( 1070040 )

          In case of a lost laptop with encryption there is something else to worry about: the strength of your passwords and the resilience against brute-forcing it.

          Rate limiters don't work. Destroy after xxx passwords also not. The attacker has the source of TrueCrypt just like you, and thus can remove that kind of limits and brute-force your password. It's almost certainly easier than brute-forcing your encryption key directly. I don't think your password is as long as your encryption key is.

          Losing your laptop w

      • Re: (Score:3, Interesting)

        by INT_QRK ( 1043164 )
        When you say people have audited, has it been been tested and assigned an Evaluated Assurance Level (EAL) under the Common Criteria (ISO 15408)? I'm not trying to be a smart-ass, but I'm asking because I'm wondering whether this might satisfy a certain proposed policy criteria that may rear its ugly head in the future...
        • Re: (Score:3, Interesting)

          by duffbeer703 ( 177751 )

          What regulators are looking for is an encryption solution whose algorithms have been certified to conform to FIPS 140-2. In general, you should only deploy encryption products in modes that are FIPS 140-2 certified.

          The "Common Criteria" EAL levels are more of a measure of the overall quality of a product's security implementation. Typically a full-disk encryption app is certified at EAL level 3 or 4.

          If you're using EAL as a decision making point, make sure that you understand how the assurance level was imp

    • by Shadow-isoHunt ( 1014539 ) on Monday February 09, 2009 @02:49PM (#26787411) Homepage
      TrueCrypt isn't without it's bugs. Both 5.1a and 6.0a have cost me two windows installs(one Win2k3, one Win XP pro), which couldn't be recovered with the recovery disk. 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. If you want something to trust your data to, truecrypt is not that program(yet).
      • by Spazztastic ( 814296 ) <`moc.liamg' `ta' `citsatzzaps'> on Monday February 09, 2009 @02:59PM (#26787599)

        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+ [] and let it go for at least two full tests? Could be one of your sticks is bad.

      • by KookyMan ( 850095 ) on Monday February 09, 2009 @03:37PM (#26788357)

        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. ( 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.

    • by trifish ( 826353 ) on Monday February 09, 2009 @02:51PM (#26787445)

      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.,2125.html []

    • by tyler_larson ( 558763 ) on Monday February 09, 2009 @03:06PM (#26787727) Homepage
      Truecrypt is fast. I have it on all my computers and backup devices that handle sensitive information, and there is zero slowdown visible to the user, even for IO-intensive operations. Steve Gibson from the "security now" podcast did his own benchmark where he created a drive image and timed how long it took to defrag the drive, then restored the bits from the image, encrypted with TC, then timed the defrag again. He then repeated the process three times because he didnt believe the results -- the encrypted filesystem ran FASTER. Take the anecdote for what it is, but the principle seems to hold true in my experience too. TrueCrypt is damn fast. It chews a few % of your CPU time when in use, but it doesnt slow things down.
    • by FictionPimp ( 712802 ) on Monday February 09, 2009 @03:14PM (#26787907) Homepage

      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.

    • Re: (Score:3, Informative)

      by tgd ( 2822 )

      TrueCrypt can't do full-drive encryption on OS X.

      You have to go commercial for that.

    • The main question is not "how?" but "why?"

      What are you trying to protect?

      From what? What attacks? What value does it have to the attacker? What value does the secret hold to you? Who are the attackers?

      For example if the value of the secret is low to you, then spending money on protecting it is a waste. Encryption costs to buy, costs to run, costs to manage keys, costs in convenience. eg. (Most secrets aren't worth a trip across town because you forgot your keys once)

      If the attackers are internal, (t

      • Re: (Score:3, Insightful)

        by guruevi ( 827432 )

        I work at a University with a Hospital attached to it:

        What are you trying to protect?
        Most likely personal identifiable information or personal health information. Could be anything from student records to social security numbers. Protected under state law and HIPAA.

        From what? What attacks? What value does it have to the attacker? What value does the secret hold to you? Who are the attackers?
        Most likely from loss or theft. The value of that information is 99% zero but our dear government has requested that a

  • by Concern ( 819622 ) * on Monday February 09, 2009 @02:18PM (#26786809) Journal

    Let me explain to you how this works. In pictures: []

    • by Sancho ( 17056 ) * on Monday February 09, 2009 @02:34PM (#26787133) Homepage

      Of course, if you're using Truecrypt, they won't know when to stop hitting you.

    • by Rinisari ( 521266 ) * on Monday February 09, 2009 @02:39PM (#26787209) Homepage Journal


      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).

      • Re: (Score:3, Funny)

        eyeballs and fingers aren't that hard to remove these days

        These days? Bodily mutilation is like the GEICO of injury - so easy, a caveman could do it.

      • eyeballs and fingers aren't that hard to remove

        Fingerprints are even easier:

        - Get a print on something.
        - "Develop" it to get a computer image of the print.
        - Fabricate a fake finger from the image any of several ways.

        One example:
        - Etch it into a printed circuit board (using a printer and a Radio Shack grade PC board etching kit.)
        - Cast a fake fingertip on the printed circuit. (Gelatin works for a few-shot prosthetic fingerpint. I think silicon caulk works too if you

    • by BenEnglishAtHome ( 449670 ) on Monday February 09, 2009 @02:42PM (#26787263)

      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.


      • by Amazing Quantum Man ( 458715 ) on Monday February 09, 2009 @03:19PM (#26788001) Homepage

        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.

      • by Estanislao Martínez ( 203477 ) on Monday February 09, 2009 @03:19PM (#26788033) Homepage

        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.

      • Re: (Score:3, Informative)

        by Blakey Rat ( 99501 )

        The point of the comic is that there's no *practical* difference between, say, 128-bit encryption and 4096-bit encryption because it is, and always will be, easier to just obtain the password somehow than to crack the encryption.

        Meanwhile, crypto-nerds go around scoffing at your primitive WPA wifi encryption and go on to introduce 47 new layers of encryption, all bigger and better than the last, wasting tons of time and money in the process.

        That message still applies, despite everything in your post.

        • by SpottedKuh ( 855161 ) on Monday February 09, 2009 @03:55PM (#26788697)

          The point of the comic is that there's no *practical* difference between, say, 128-bit encryption and 4096-bit encryption [...]

          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) [], 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.

        • it is, and always will be, easier to just obtain the password somehow than to crack the encryption.

          You can use drugs and a wrench on a few people. You can't do it to a couple hundred million people. When someone drugs you and hits you with a wrench, you know it happened. Try it on a massive scale and the public will find out and grab wrenches of their own.

          That is why hard-to-crack encryption is still incredibly useful. It allows you to deny the enemy the option of attacking undetected.

          And that just

    • No. Let me explain to you how this works, with a story link [].

      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.

  • SAIC used encryption on all of their Windows laptops. There was a huge speed penalty in startup time and starting applications.

  • Yeah... (Score:3, Insightful)

    by bytethese ( 1372715 ) on Monday February 09, 2009 @02:20PM (#26786845)
    Don't do it.

    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)

      by quickOnTheUptake ( 1450889 ) on Monday February 09, 2009 @02:35PM (#26787145)
      I've heard that full fs encryption on higher end computers has a negligible performance impact (cpu can generally keep up with the hdd) but on lower end machines esp. netbooks, the performance impact can be appreciable. Here is an article with benchmarks []
    • Re:Yeah... (Score:5, Interesting)

      by number11 ( 129686 ) on Monday February 09, 2009 @02:37PM (#26787183)

      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.

    • Re:Yeah... (Score:5, Interesting)

      by Lumpy ( 12016 ) on Monday February 09, 2009 @02:40PM (#26787235) Homepage

      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."

      • Re:Yeah... (Score:4, Interesting)

        by SatanicPuppy ( 611928 ) * <> on Monday February 09, 2009 @02:59PM (#26787613) Journal

        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.

      • Re:Yeah... (Score:5, Informative)

        by Vancorps ( 746090 ) on Monday February 09, 2009 @03:02PM (#26787659)

        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.

      • Re:Yeah... (Score:5, Insightful)

        by Kjella ( 173770 ) on Monday February 09, 2009 @03:03PM (#26787677) Homepage

        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.

  • Dont. (Score:5, Insightful)

    by spikenerd ( 642677 ) on Monday February 09, 2009 @02:23PM (#26786911)
    "Security" that gets in people's way is a security threat, because people will find a way to work around it, and be worse off because of it. Never try to lock down everything, or you'll have no control over what is compromised. Figure out what you really need to secure, and lock that down. Really. Trying to secure everything is a sure sign that someone lacks the knowledge to make security decisions.
    • Re: (Score:3, Interesting)

      by Rageon ( 522706 )
      I work in a state courthouse. Here, Windows is set up force new passwords every so often and of ridiculous complexity (numbers + letters + symbols + sanskrit, or something of that nature). So what we have is a situation where 50% of the computers here have little post-it on them with the user's passwords. It does far more harm than good.
      • I've seen this, too (Score:4, Interesting)

        by Wee ( 17189 ) on Monday February 09, 2009 @03:48PM (#26788559)
        The university where I worked a few years ago had a very draconian password scheme. A lot of the profs and TAs and such kept their passwords on post-its, pieces of paper on their desks, etc. One professor's "security measure" was a post-it that reminded him to remove the password post-it before office hours. I'm pretty sure more than one student changed their grades or grabbed a test or something at some point.

        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.


  • password (Score:2, Insightful)

    by Anonymous Coward

    Encryption is easy. Password distribution and protection is hard.

  • Key Management (Score:3, Insightful)

    by John Hasler ( 414242 ) on Monday February 09, 2009 @02:26PM (#26786967) Homepage

    Have you worked out a complete plan for key management for all these encrypted devices?

  • Pointsec (Score:2, Informative)

    Open source? Nope. But Pointsec is an impressive product. I've been using it for years and have noticed zero performance impact.
    • Truecrypt has worked well for me on my laptop for a long time - which runs Vista and crashes on a weekly or more basis, so far never causing data loss on the Trucrypt drive. For office applications at least there is no noticeable performance hit.
  • Its cross platform. But, it does not support whole disk encryption for Linux or Mac.
  • unless of course your requirements call for it. But your systems will run very slow if every time they have to boot they have to go thru the decrypt process. you should only need to encrypt your users' data. Hopefully, system data and user data are, at least, in different folders of the filesystem.
    • by Hatta ( 162192 )

      You'd be surprised. Modern CPUs can decrypt a file as fast as the disk can retrieve it. Even encrypting your swap imposes negligible performance penalties.

  • Key Management? (Score:5, Insightful)

    by HockeyPuck ( 141947 ) on Monday February 09, 2009 @02:32PM (#26787079)

    What's your key management strategy?

  • TrueCrypt and Mac (Score:4, Informative)

    by Danathar ( 267989 ) on Monday February 09, 2009 @02:33PM (#26787107) Journal

    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).

    • PointSec and WinMagic also support pre-boot on the Mac. WinMagic also supports booting from the Segate hardware encryption drives on a Mac.
  • by York the Mysterious ( 556824 ) on Monday February 09, 2009 @02:36PM (#26787155) Homepage
    I see a lot of comments here suggesting that this is a bad idea, and to a certain extent it is, but chances are the institution has no say in this. After the wave of laptop thefts from government institutions, the office of inspector general requires all laptops (and portable media) be encrypted. A lot of agencies have stalled on this one. I've been involved in supporting laptops that are encrypted and go out to remote field cables (as remote as it gets). It's pain, but if you have to do it, TrueCrypt is not the way to go. You need something that ties into AD and something that can manage thousands of users. PGP Desktop.
  • Just don't do it. (Score:5, Insightful)

    by SatanicPuppy ( 611928 ) * <> on Monday February 09, 2009 @02:36PM (#26787161) Journal

    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.

  • I was screaming PGP until I got to the Open source part, removing funding from the equation Truecrypt is the only thing that will really do what your asking for. Its not bad & I like it, but its not PGP. And if you have been using something since the BBS days, your really not likely to change now so I am bias towards it. But from my limited (3 month) run with Truecrypt I had no problems and it was very stable, and little to no real performance difference from PGP's.

  • Full Disk Encryption and of course encrypting our USB keys, backup DVDs, etc. Central key management, recovery, pretty well thought out.

    I dunno if the 'free' version does all this. It's not as clever as TruCrypt, but it works.

  • ROT 26 (Score:5, Funny)

    by spike2131 ( 468840 ) on Monday February 09, 2009 @02:44PM (#26787307) Homepage

    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)

      by Red Flayer ( 890720 ) on Monday February 09, 2009 @03:07PM (#26787755) Journal
      That'll never work, it's too obvious. Even the PHBs recognize that there are 26 letters in the alphabet... that number may raise questions.

      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.
  • by AMuse ( 121806 ) <slashdot-amuse&foofus,com> on Monday February 09, 2009 @02:53PM (#26787519) Homepage

    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.

  • by BenEnglishAtHome ( 449670 ) on Monday February 09, 2009 @02:59PM (#26787597)

    I've used these products [] for a long time. (There are others; look around.) I suggest you phase 'em in over the next three years, by which time you'll have replaced everything. After all, you already have a budget for replacing all hardware over the next few years, right? Beyond that, remote, enterprise-quality tools for managing this hardware can be *very* pricey add-ons, but if you build your work processes right, there may be little or no need for them.

    That just leaves writing to CDs/DVDs. There are open-source packages such as TrueCrypt. If you're already running WinZip, it'll do the same for removable media, allowing your users to set a specific password for that write then sneakernet the disk wherever it needs to go. If you want to force all writes to optical media to be encrypted, you'll need to look at something like GuardianEdge Removable for a commercial app or something inventive if you must go open-source.

    One last thought: If your data is so important, so valuable, or so legally regulated that you must encrypt *everything*, then you have the money to go open-source, commercial, or whatever works. I see no justification in the submitted question for limiting the choice to open-source software. If you *have* to do this, you *have* to do it right, no matter the cost. If your big guys say they can't afford the cost, then they don't *have* to do it.

  • by Jane Q. Public ( 1010737 ) on Monday February 09, 2009 @03:00PM (#26787633)
    I second the opinion of the first poster who recommended you wait, for several reasons.

    First, most methods of encryption are a pain in the butt. If you want to encrypt only some data, then yes I would say Truecrypt. But then it has to be manually un-encrypted before use.

    If you want to encrypt whole drives, your network, everything, and have it work transparently, you are in for a headache combined with a nightmare. Headache because getting it set up and working is a major project fraught with problems. Nightmare because you will lose whole drives worth of data when something goes wrong, unless you have a very serious, robust, and reliable backup scheme that you use often.

    However, drive manufacturers will be coming out soon with new drives that incorporate DES encryption via hardware. This eliminates the delays and problems with software encryption, and will go a very long way toward making whole-network encryption a lot more practical.
  • by flyingfsck ( 986395 ) on Monday February 09, 2009 @03:38PM (#26788377)
    The procedure for handling keys and data at rest is important. If you are worried about users forgetting their passwords, then use key tokens (USB memory sticks). This will work if the machine and the stick are not kept in the same bag. In other words, have the users clip the sticks to their key chains.
  • by Bearhouse ( 1034238 ) on Monday February 09, 2009 @03:57PM (#26788733)

    "My institution has thousands of computers, and is looking at starting an IT policy to encrypt everything"

    You're looking at a world of potential support pain. Lost passwords, lost unrecoverable files...

    For those advocating Truecrypt, my understanding is that it lacks the enterprise deployment and management tools of something like PGP.

    You're talking about a fundamental change in your IT landscape, with significant implications for implementation & support cost. Get help.

  • by jafo ( 11982 ) on Monday February 09, 2009 @04:03PM (#26788859) Homepage

    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.


  • by Kazoo the Clown ( 644526 ) on Monday February 09, 2009 @04:50PM (#26789581)
    If you don't ever want to discover that your data is inaccessible, you have to think about whether or not you'll let individual users set any encryption passwords, and how to make sure there's always more than one person who knows any given encryption passwords, and whether or not you'll let all the people who may know a given password get on the same airplane. Because if someone forgets, gets hit by a bus, gets pissed off at the company, etc., you may just find some data just became inaccessible...
  • by multimediavt ( 965608 ) on Monday February 09, 2009 @04:54PM (#26789625)

    Ok, so I guess it's pointless to argue the point of "Why encrypt 'everything'?" There are options out there, but I think you're going to be creating an incredible hit on productivity in the institution and a massive support nightmare depending on the size of your site. Also, keep in mind that you will need to establish a tiered encryption system and master keys that will open everything in every department and agency at the highest administrative level of the organization. There will also have to be new physical security practices to make sure the keys don't get into the wild, as well as a rotating scheme for replacing all the keys on a regular basis and updating all masters.

    Look, I have been on both sides of this argument and know that there are things that you haven't even thought about from the business practices and risk management angles that will have a tremendous set of REAL costs that are beyond the performance overhead on the computing side of things. This is a horribly bad idea! The Pentagon, CIA and DHS don't encrypt everything for a good reason!

  • by Xerolooper ( 1247258 ) on Monday February 09, 2009 @04:56PM (#26789663)
    Yes we encrypt every device(With the exception of PC's). We have not implemented the insert=forced encrypt yet because there are certain software products that use usb dongles that would be encrypted by that policy and they have not worked that out yet. Cameras are a pain and our work requires we use them they are the few times we get viruses although that is not an encryption issue.

    We don't use an open source product except TruCrypt on some of my own portable HDD's. I am pushing that more so we don't have to buy licenses for every piece of hardware. Automation (see below) is a step in that direction. My experiences may still help.

    First where I do use TruCrypt I set up a batch file that opens a simple prompt so the user just enters a password and the drive becomes accessible. The batch file and the TrueCrypt executable both reside on a small unencrypted partition on the drive in question with an autorun.inf file pointing to the batch file. To automatically mount any encrypted volume it sees on the disk you just inserted it goes something like this:
    TrueCrypt\TrueCrypt /a devices /q /e /rm

    Second we use Encryption Plus Hard Disk for our laptops. PC's are not encrypted we invested in a controlled access security system instead of purchasing licenses for all PC's although unlike other /.'rs I can see why you might want to encrypt everything. If your building security is not super tight or just not possible. You have to weigh the possiblity of theft of equiptment against how sensitive your data is.

    Like TrueCrypt our software loads a driver that encrypts and decrypts everything written to the HDD. As you probably know computers aren't always writing to the HDD. So the idea that you'll take a huge performance hit is kind of a misnomer. We have laptops that range from Pentium III's to the latest cpu's. If the laptop is excruciatingly slow to begin with then encrypting the HDD will only make it slightly more excruciating. If the cpu is more current then the user will not notice the difference.

    Yes people loose passwords and forget the challenge questions. Unfortunately here we don't have a good procedure in place to reset them remotely. We have them bring them in and we enter the admin password. Even if the HDD crashes we can pop in the decryption CD and get their data about 50% of the time. Which is not all that far off from the recovery achieved from our unencrypted PC's after HDD crashes.

    In conclusion having imaged and encrypted hundreds of PC's I would say unless you choose the wrong algorithm don't worry to much about performance issues. The most basic algorithms will stop 99% of common thief's from getting at your data. Of course if your worried about the uncommon ones you may have to weigh protection verses performance.
  • by zifr ( 1467429 ) on Monday February 09, 2009 @04:59PM (#26789693)
    My company has been encrypting everything for some time. We have used Truecrypt with no issues for around 1.5 years I believe. Our linux machines are all encrypted. It's easy to implement with Fedora 9+ and Ubuntu 8.10 alternate installer as Anaconda handles it for you. I also have several encrypted RAID arrays. If you want pm me for a write up on it. I don't want my site getting slashdotted ;) . I'll be happy to give you my how-tos' Just remember, nothing is 100% secure. Document everything. As far as performance is concerned. We have noticed no significant impact from disk encryption. Let all the naysayers whine and say I'm full of it. TOP reports that our encryption from cryptsetup consumes about 5% of our procs on our older IBM celerons 2ghz, that's while writing to an array. The array (mdadm) consumes about another 5 %. It consumes around the same on a single core of our new machines. Our new machines, i.e. Core2Duo 2.2's, Xeon Quads 2.13's and an AMD dual core 2.2 you don't even notice it. Frankly it's so easy to encrypt a system drive these days I am of the mind you are foolish not to do so. The only downside I have come across with system encryption is that I can't do remote reboots. There is a way around it I've read but it's not really an issue for us. Message me if you want, or can. I never have pm'd anyone here before.
  • by DarthVain ( 724186 ) on Monday February 09, 2009 @05:01PM (#26789713)

    We have many of the same problems where I work in government. I am not sure how the posters work is organized, but I know at least mine seems ass backwards at times. Its a problem of control and responsibility.

    I assume at the corporate level they manage our servers and centralized data holdings in a secure fashion with encryption. This also includes some items like individual email stored centrally.

    However where I work, everything on your personal computer, which everyone has, is the responsibility of your program, and ultimately the individual to back up.

    So in this lunacy you have in some cases triple protected, rotating passwords on systems, yet next to the box is a USB drive that is unsecured, that contains all the data on said system. In a word, stupid.

    Part of the problem is the rotating passwords. If you do backup you have to do it manually as when your password changes it will break Microsoft's "Scheduled Tasks" (which requires a password, and it is hardcoded). Centrally they really don't seem to care, as it "is not their problem", that is the users responsibility.

    So people being people, and busy at that, most do not back up regularly, and none I know encrypt. Though part of the problem being also that no policy exists that I know of about encryption, which to use, what is acceptable, etc... Franking I don't see IT wanting to create devices they themselves cannot crack as well, which means some kind of backdoor.

    Anyway any advice as to product (I hear TrueCrypt mentioned a lot), or a solution to the automation process that doesn't involve A)Super User Privs, or B)Not having pssword changes, as I don't think IT would ever go for either of those. I have looked around online but I have yet to find anything that easily solves this problem. Also changing to Linux is also not an option.. :) I have to work with what I have!

  • Servers? (Score:3, Insightful)

    by Goonie ( 8651 ) <> on Monday February 09, 2009 @05:09PM (#26789843) Homepage
    laptops and desktops, sure, but I'd be a bit hesitant about doing this on application servers until I was absolutely sure it wasn't going to cause a nasty performance hit. Furthermore, make sure you've got a very, very good backup strategy first.
  • Thin client (Score:3, Interesting)

    by bugs2squash ( 1132591 ) on Monday February 09, 2009 @05:14PM (#26789897)
    It seems to me that the main problem with recent stupid leaks of large amounts of information from stolen laptops was not so much that the laptop was unsecured, but that the data had no place being on the laptop anyway.

    Especially now that you can reach a good network from almost anywhere in the USA, even while traveling along the road. Being able to work on real data from a social security database while flying on an airplane is simply not a reasonable thing to ask.

    Can you not start with a core to your network that includes all the encryption you want and then push outwards as you need to.

    Maybe set-up a central server or two that users can VPN into using a thin client. Prohibit wholesale copying of data (sure, they can take a screenshot and paste it into powerpoint, or write some information down off of the screen, but forbid file downloads.

    Then, for some of your employees, give them a locked-down environment on their PC that has greater access permissions.

    The point being, for many users, thin client may suffice and its much easier to protect. And for those for whom it just won't do, you can spend some more time and education on getting them a solution they can work with and make them aware that by and large sensitive data does not belong on a mobile device.

    It's not as if you are going to really encrypt everything anyway - you want people to be able to read printouts !

    I imagine that you just want to secure data at rest on your central servers and data on the move between the servers and the clients, except in a very few specific cases.

Things are not as simple as they seems at first. - Edward Thorp