Slashdot Mirror


How To, When You Have To Encrypt Absolutely Everything?

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

5 of 468 comments (clear)

  1. TrueCrypt or Wait for On Drive Upgrades by eldavojohn · · 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 which boasts:

    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.

    --
    My work here is dung.
    1. Re:TrueCrypt or Wait for On Drive Upgrades by TheCabal · · 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.
      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 /noisocheck).

      Seriously, a little research isn't hard.

  2. Re:Yeah... by quickOnTheUptake · · Score: 5, Informative

    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

    --
    Mod points: Guaranteed to remove your sense of humor.
    Side effects may include gullibility and temporary retardation
  3. You're still missing the point. by Estanislao+Mart�nez · · 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.

  4. Re:Theory vs. Reality - Seriously by SpottedKuh · · Score: 5, Informative

    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.