Re: How does whole-disk encryption work?

Discussion in 'Computer Security' started by nemo_outis, Jan 4, 2010.

  1. nemo_outis

    nemo_outis Guest

    Prof Wonmug <> wrote in news:1mc4k51ehfcbg7i6udbk0dopct1qe6d23q@

    > In another thread, nemo suggested I consider "whole disk" encryption
    > with something like using truecrypt, bestcrypt, PGP wholedisk,
    > drivecrypt, free compusec, etc.
    > I would like to understand how this works and what the disadvantages
    > are.
    > 1. I assume all of the above are software solutions, right? Does the
    > data on the disk remains encrypted? Does the encryption software
    > intercept the reads and writes to do the decryption and encryption on
    > the fly?

    My list above is not exhaustive - there are others. All are software solutions
    (for Windows OS primarily although some offer linux versions - in fact, Linux has
    whole-disk encryption as an option "inherently"). Truecrypt and PGP Wholedisk are
    (quasi) open source. Truecrypt and Free Compusec are free. Some packages have
    "enterprise" features that may appeal to those in a corporate environment (master
    passwords, single signon, etc.) My personal preference is Bestcrypt.

    > 2. Is it transparent to all of the applications (Word, Excel, Outlook,
    > Explorer, etc.)?

    Yes, compeletely transparent to everything on the computer.

    > 3. Do I have a second password to enter? (One for logging into Windows
    > and one for the encrypted data?)

    The common case is one password at bootup to unlock the encryption after which
    everything then apparently proceeds "as if" there was no encryption. (e.g., you
    will be subsequently asked for your windows name and password as it fires up and
    in every other way you will operate "normally") (In fact, after setup, whole-disk
    encryption requires next to no intervention by the user and is easier than other
    encryption methods for the inexperienced user.) A few encryption packages offer
    "single sign on" merging the bootup and windows signon (typically only offered in
    the enterprise/corporate verisons).

    > 4. Does it affect system performance? How much?

    Completely undiscernible effect on speed on any modern computer (I estimate less
    than a 5% hit on disk reads/writes and the CPU load is negligible)

    > Thanks



    1. You MUST remember your password or you're hooped - after all, that's the whole
    point of "unbreakable encryption." (There are a number of ways to go about this
    such as storing keyfiles, etc that also aid disaster recovery. Enterprise
    versions usually have have some sort of master password, administrator, etc.

    2. While all the major brands of such software are very robust (I have literally
    "pulled the plug" on Free Compusec as it was encrypting everything for the first
    time only to have it resume flawlessly next bootup with no data loss) it would be
    folly not to make an unencrypted backup of everything before encrypting it
    (including *testing* that the data can be restored). Remember: the time you are
    most likely to screw things up from "operator error" is when you first start using
    the encryption software. Plus having a rock-solid backup makes you much less
    nervous about fully exploring the software's features.

    Periodically thereafter you make additional backups (encrypted or otherwise - your
    choice). In short, encrypting everything should make you much more punctilious
    about regular backups, because the consequences of a fuckup can be considerably
    higher. However, I don't want to scare you off encryption - if you have backed up
    the keyfiles/headers (usually conveniently packaged as a "standard procedure" with
    the encryption software) then you are not much more vulnerable to failures than
    when unencrypted (e.g., a hardware sector glitch will corrupt only one file, not
    your whole drive).

    Some time back I wrote a detailed "drill" for how to go about whole-disk
    encryption with minimal risk of screwing up catastrophically - I can post it if
    you wish.
    nemo_outis, Jan 4, 2010
    1. Advertisements

  2. nemo_outis

    nemo_outis Guest

    Arthur T. <> wrote in

    > In Message-ID:<Xns9CF6AC08F4DC3pqwertyu@>,
    > "nemo_outis" <> wrote:
    >>Some time back I wrote a detailed "drill" for how to go about
    >>whole-disk encryption with minimal risk of screwing up
    >>catastrophically - I can post it if you wish.

    > I'm not sure when I'll move up to whole-disk encryption, but
    > I'd like to see your drill. You have a level of "professional
    > paranoia" I respect, and I'd like to see what steps I might have
    > missed.
    > I looked in your old posts (the ones I have) and I can't find it.
    > I did find another post where you said that you had (somewhen)
    > posted your scheme for backups, but again I didn't find the scheme
    > itself.
    > (When I tried to undo the boot passwording of Free Compusec, it
    > didn't work right, and I had to restore the boot record (which I had
    > backed up before pulling the trigger).)

    Here's my post from the mists of time:

    and a slight variant on it:

    Points I may not have emphasized enough back then are:

    1) The need to backup the original MBR (better, all track 0) of the *unencrypted*
    boot/system disk (I'll assume boot & system are the same, as is commonly the case,
    and I'll ignore the complications of dual-boot systems, multiple partitions,
    etc.). Many backup programs skip backing it up (at least unless you carefully
    configure them otherwise) and since most full HD OTFE encryption programs
    overwrite it, you may need the original MBR/track0 if you decide to abandon
    encryption and restore the drive to the unencrypted state. (You're not stuck if
    you haven't backed it up but you'll need to do a bit of jacking around in that
    case - PITA)

    2) The desirability of backing up the MBR (actually, all track 0) of the
    *encrypted* boot/system drive. Many of the encryption programs can do this for
    you as part of making a restore/recovery diskette (or equivalent) but check to
    make sure they fully accomplish this. RTFM :)

    If you're paranoid (and I would argue that you should be) you should restore
    (and/or hash verify) track 0 anytime your laptop might have been exposed to
    surreptitious diddling. This precaution is part of the famous "two-boot"
    operational procedure: Boot first with the rescue/restore/MBR/track0/hash-verify
    source to verify/restore a "clean" track 0, and then boot a second time "for
    real" directly from the machine's "confirmed clean" encrypted boot/system drive.

    Real paranoids will make sure that the MBR/rescue media is "known-good" and
    "tamper/counterfeit-resistant." (A CD with half a torn dollar bill securely glued
    to it is one choice. Incidentally, the other half of the torn dollar bill is kept
    elsewhere for occasional verification.) Following this two-boot drill will make
    you much more resistant to Rutkowska's "evil maid" attack.

    3) Lastly, I urge you to back up the portion of the encrypted drive that is the
    "encryption header" for each drive/partition (It may not be called quite that, the
    manufacturer will likely made sure it has no "fingerprint" and so it's impossible
    to identify, and - catch 22- its exact location may not be clearly documented).
    Having a copy of it will make it much easier to recover from a variety of errors,
    mistakes, and glitches on your encrypted system - such as a dead sector in the
    header area. Fortunately, most modern packages have some provision for backing
    this up for you as part of making a rescue/recovery/admin disk (etc.) but check to
    be sure - RTFM :) However, if you're religious about making regular backups you
    can probably skip doing your own manual backup of the header.

    nemo_outis, Jan 5, 2010
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ayosha

    Whole disk encryption advice needed

    ayosha, Aug 29, 2003, in forum: Computer Security
    John Veldhuis
    Sep 2, 2003
  2. Peter L

    Whole Hard Disk Encryption?

    Peter L, Apr 24, 2004, in forum: Computer Security
    Doctor Who
    May 9, 2004
  3. Regis

    Re: How does whole-disk encryption work?

    Regis, Jan 4, 2010, in forum: Computer Security
    Jan 8, 2010
  4. Frank Merlott

    Re: How does whole-disk encryption work?

    Frank Merlott, Jan 5, 2010, in forum: Computer Security
    Jan 6, 2010
  5. noauth

    Re: How does whole-disk encryption work?

    noauth, Feb 4, 2010, in forum: Computer Security
    Feb 4, 2010