Results 1 to 17 of 17

Thread: How does whole-disk encryption work?

  1. #1
    Prof Wonmug
    Guest

    How does whole-disk encryption work?

    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?

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

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

    4. Does it affect system performance? How much?

    Thanks

  2. #2
    Regis
    Guest

    Re: How does whole-disk encryption work?

    Prof Wonmug <wonmug@e.mcc> writes:

    > 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?
    >
    > 2. Is it transparent to all of the applications (Word, Excel, Outlook,
    > Explorer, etc.)?
    >
    > 3. Do I have a second password to enter? (One for logging into Windows
    > and one for the encrypted data?)
    >
    > 4. Does it affect system performance? How much?


    Yes on all counts. They're software solutions, transparent to
    individual applications, OS Performance hit varies on implementation,
    I imagine. I can offer my experience with PGP full disk encryption on
    a core2 solo (i.e. one active core) laptop you kinda noticed it, but
    not terribly. Then again, disk i/o intensive operation wasn't part of
    my workload on that machine.

    Various products also have a notion of volume/folder encryption
    whereby you have an encrypted file that windows mounts in a way that
    makes it look like a disk drive to the OS. As such, the apps don't
    care, as it is abstracted on the OS level. In addition to hooks in
    the OS, there's a bootloader component to full disk crypto too, but
    I'm ignorant of the details. You may or may not involve a 2nd
    password. PGP for instance can be configured to use Windows
    authentication for its full disk encryption in which case you are
    prompted for the windows password on bootup, but don't have to enter
    it into the usual windows login screen.

    The downsides of full disk crypto is that if the encrypted volume gets
    corrupted, you can have quite a headache on your hands where the usual
    methods of trying to pull data off a damaged drive have another layer
    of crypto on top, and it's a whole lot easier to lose your data if you
    aren't fastidious about backing up. And naturally, if you forget the
    password, you are quite screwed.

    I haven't done multiple OS's with full disk encryption, and I have a
    vague notion that there's enough OS dependency that you can't expect
    to boot multiple OS's if you have full disk encryption. Then again I
    know some of the list presented above are available for multiple
    platforms, and I'm ignorant to the particulars, but I believe that if
    you need to dual boot windows/*nix, you can use partition level
    encryption at best. I'm sure someone will set me straight if I'm
    wrong on that, though.






  3. #3
    Prof Wonmug
    Guest

    Re: How does whole-disk encryption work?

    On Mon, 04 Jan 2010 14:24:40 -0600, Regis <ordsec@gmail.org> wrote:

    >Prof Wonmug <wonmug@e.mcc> writes:
    >
    >> 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?
    >>
    >> 2. Is it transparent to all of the applications (Word, Excel, Outlook,
    >> Explorer, etc.)?
    >>
    >> 3. Do I have a second password to enter? (One for logging into Windows
    >> and one for the encrypted data?)
    >>
    >> 4. Does it affect system performance? How much?

    >
    >Yes on all counts. They're software solutions, transparent to
    >individual applications, OS Performance hit varies on implementation,
    >I imagine. I can offer my experience with PGP full disk encryption on
    >a core2 solo (i.e. one active core) laptop you kinda noticed it, but
    >not terribly. Then again, disk i/o intensive operation wasn't part of
    >my workload on that machine.
    >
    >Various products also have a notion of volume/folder encryption
    >whereby you have an encrypted file that windows mounts in a way that
    >makes it look like a disk drive to the OS. As such, the apps don't
    >care, as it is abstracted on the OS level. In addition to hooks in
    >the OS, there's a bootloader component to full disk crypto too, but
    >I'm ignorant of the details. You may or may not involve a 2nd
    >password. PGP for instance can be configured to use Windows
    >authentication for its full disk encryption in which case you are
    >prompted for the windows password on bootup, but don't have to enter
    >it into the usual windows login screen.
    >
    >The downsides of full disk crypto is that if the encrypted volume gets
    >corrupted, you can have quite a headache on your hands where the usual
    >methods of trying to pull data off a damaged drive have another layer
    >of crypto on top, and it's a whole lot easier to lose your data if you
    >aren't fastidious about backing up. And naturally, if you forget the
    >password, you are quite screwed.
    >
    >I haven't done multiple OS's with full disk encryption, and I have a
    >vague notion that there's enough OS dependency that you can't expect
    >to boot multiple OS's if you have full disk encryption. Then again I
    >know some of the list presented above are available for multiple
    >platforms, and I'm ignorant to the particulars, but I believe that if
    >you need to dual boot windows/*nix, you can use partition level
    >encryption at best. I'm sure someone will set me straight if I'm
    >wrong on that, though.


    I use Carbonite for backup. It does it continually. Would the files
    that go to Carbonite for backup be encrypted or clear?

  4. #4
    nemo_outis
    Guest

    Re: How does whole-disk encryption work?

    Prof Wonmug <wonmug@e.mcc> wrote in news:1mc4k51ehfcbg7i6udbk0dopct1qe6d23q@
    4ax.com:

    > 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


    Regards,

    PS

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

    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 ****up 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.









  5. #5
    Arthur T.
    Guest

    Re: How does whole-disk encryption work?

    In Message-ID:<Xns9CF6AC08F4DC3pqwertyu@69.16.185.250>,
    "nemo_outis" <abc@xyz.com> 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).)


    --
    Arthur T. - ar23hur "at" intergate "dot" com
    Looking for a z/OS (IBM mainframe) systems programmer position

  6. #6
    nemo_outis
    Guest

    Re: How does whole-disk encryption work?

    Arthur T. <arthur@munged.invalid> wrote in
    news:mf75k5tr62p9g5an0iuocim5bgo1b1e5v9@4ax.com:

    > In Message-ID:<Xns9CF6AC08F4DC3pqwertyu@69.16.185.250>,
    > "nemo_outis" <abc@xyz.com> 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:

    http://www.google.com/url?
    url=http://groups.google.com/g/f447ff0a/t/ce4ac3ab8eedd648/d/4ca9847e74dea09a%
    3Fhl%3Den%26q%3Dbackup%2Bencryption%2Bdrill%2Bauthor:outis%
    234ca9847e74dea09a&ei=J7ZCS_CnPKaCkAS4hNT2CQ&sa=t&ct=res&cd=2
    &source=groups&usg=AFQjCNHwon0WISjERu-gvkhvhhxuvI2k1Q

    and a slight variant on it:

    http://www.google.com/url?
    url=http://groups.google.com/g/f447ff0a/t/f016a6ef97f31cfa/d/e1c764e31b55967f%
    3Fhl%3Den%26q%3Dbackup%2Bencryption%2Bdrill%2Bauthor:outis%
    23e1c764e31b55967f&ei=J7ZCS_CnPKaCkAS4hNT2CQ&sa=t&ct=res&cd=1
    &source=groups&usg=AFQjCNFY5zucu03K3XQUEooi7tqH6kfm8w

    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.

    Regards,


  7. #7
    Arthur T.
    Guest

    Re: How does whole-disk encryption work?

    >> In Message-ID:<Xns9CF6AC08F4DC3pqwertyu@69.16.185.250>,
    >> "nemo_outis" <abc@xyz.com> 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.

    >>

    >
    >Here's my post from the mists of time:


    Thanks for the links. I'll study the posts.

    --
    Arthur T. - ar23hur "at" intergate "dot" com
    Looking for a z/OS (IBM mainframe) systems programmer position

  8. #8
    Frank Merlott
    Guest

    Re: How does whole-disk encryption work?

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


    I do not trust Compusec because I read somewhere on their site that they
    could reset the password.

    I would also consider Diskcryptor, the only fully GPL licensed whole
    disk encryption product.


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


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


    Only if you set up a Windows password logon you will have two, otherwise
    just one.
    >
    > 4. Does it affect system performance? How much?



    Not really noticeable, specially in todays computers.


    --
    Privacylover: http://www.privacylover.com

  9. #9
    Regis
    Guest

    Re: How does whole-disk encryption work?

    Prof Wonmug <wonmug@e.mcc> writes:

    > I use Carbonite for backup. It does it continually. Would the files
    > that go to Carbonite for backup be encrypted or clear?


    If Carbonite stores to a volume or disk that is not encrypted, the
    backup would be unencrypted. If carbonite is backing up to a volume
    or disk that is under the management of the disk encryption product,
    the files would be encrypted.



  10. #10
    nemo_outis
    Guest

    Re: How does whole-disk encryption work?

    "Frank Merlott" <frank@nomail.com> wrote in
    news:op.u52by7vulcf8dn@aopenxpc:

    ....
    > I do not trust Compusec because I read somewhere on their site that
    > they could reset the password.


    They can only recover your password for you (or anyone else) **IF** you send them
    your security.dat file. Normally this file is stored fully encrypted along with
    everthing else on the HD and so is completely inaccessible to any "evildoer."

    If you store an additional backup copy of it elsewhere (as you should) then you must
    take care to protect it (either by bombproof physical security or by encrypting it,
    possibly with something as simple as winrar or pkzip Of course, you would then have
    to remember the zip password - do I see an infinite recursion developing :-)


    > I would also consider Diskcryptor, the only fully GPL licensed whole
    > disk encryption product.


    Yep, another good free one. As I said in an earlier post, my list is not exhaustive
    - there are others of the breed, each with its own distinguishing features, such as
    Wnmagic's Securedoc, Utimaco's Safeguard, etc.

    ....

    Regards,

  11. #11
    Prof Wonmug
    Guest

    Re: How does whole-disk encryption work?

    On Tue, 05 Jan 2010 10:26:38 -0600, Regis <ordsec@gmail.org> wrote:

    >Prof Wonmug <wonmug@e.mcc> writes:
    >
    >> I use Carbonite for backup. It does it continually. Would the files
    >> that go to Carbonite for backup be encrypted or clear?

    >
    >If Carbonite stores to a volume or disk that is not encrypted, the
    >backup would be unencrypted. If carbonite is backing up to a volume
    >or disk that is under the management of the disk encryption product,
    >the files would be encrypted.


    Carbonite backs up over the Internet to their server. I'm wondering if
    the type of reads they use access the data before or after decryption.

  12. #12
    Regis
    Guest

    Re: How does whole-disk encryption work?

    Prof Wonmug <wonmug@e.mcc> writes:

    > On Tue, 05 Jan 2010 10:26:38 -0600, Regis <ordsec@gmail.org> wrote:
    >
    >>Prof Wonmug <wonmug@e.mcc> writes:
    >>
    >>> I use Carbonite for backup. It does it continually. Would the files
    >>> that go to Carbonite for backup be encrypted or clear?

    >>
    >>If Carbonite stores to a volume or disk that is not encrypted, the
    >>backup would be unencrypted. If carbonite is backing up to a volume
    >>or disk that is under the management of the disk encryption product,
    >>the files would be encrypted.

    >
    > Carbonite backs up over the Internet to their server. I'm wondering if
    > the type of reads they use access the data before or after decryption.


    Almost certainly after encryption, therefore, what's backed up on
    carbonite's server is your original unecnrypted file (assumably
    encrypted using whatever encryption their client uses when sending
    it).

    Remember, full disk encryption is transparent to apps, to assuming
    carbonite has a software client that runs on your machine, carbonite
    will make some api call to read a file from teh OS, the full disk
    encryption software is shimmed into the operating system making that
    call look very normal to carbonite's client, the os reads the
    encrypted stuff off the disk, the full disk encryption software's shim
    decrypts it, hands it off to the carbonite client unencrypted, whereby
    I imagine carbonite's client re-encrypts it in whatever way carbonite
    uses, then sends it off to carbonites server.

    In short, Carbonite will behave exactly as it does on a system without
    full disk encryption.




  13. #13
    Regis
    Guest

    Re: How does whole-disk encryption work?

    Regis <ordsec@gmail.org> writes:

    > Prof Wonmug <wonmug@e.mcc> writes:
    >
    >> On Tue, 05 Jan 2010 10:26:38 -0600, Regis <ordsec@gmail.org> wrote:
    >>
    >>>Prof Wonmug <wonmug@e.mcc> writes:
    >>>
    >>>> I use Carbonite for backup. It does it continually. Would the files
    >>>> that go to Carbonite for backup be encrypted or clear?
    >>>
    >>>If Carbonite stores to a volume or disk that is not encrypted, the
    >>>backup would be unencrypted. If carbonite is backing up to a volume
    >>>or disk that is under the management of the disk encryption product,
    >>>the files would be encrypted.

    >>
    >> Carbonite backs up over the Internet to their server. I'm wondering if
    >> the type of reads they use access the data before or after decryption.

    >
    > Almost certainly after encryption,


    doh. s/encryption/decryption/ Sorry for the possibly confusing
    typo.

    > therefore, what's backed up on
    > carbonite's server is your original unecnrypted file (assumably
    > encrypted using whatever encryption their client uses when sending
    > it).
    >
    > Remember, full disk encryption is transparent to apps, to assuming
    > carbonite has a software client that runs on your machine, carbonite
    > will make some api call to read a file from teh OS, the full disk
    > encryption software is shimmed into the operating system making that
    > call look very normal to carbonite's client, the os reads the
    > encrypted stuff off the disk, the full disk encryption software's shim
    > decrypts it, hands it off to the carbonite client unencrypted, whereby
    > I imagine carbonite's client re-encrypts it in whatever way carbonite
    > uses, then sends it off to carbonites server.
    >
    > In short, Carbonite will behave exactly as it does on a system without
    > full disk encryption.
    >
    >
    >


    --

  14. #14
    ♥Ari♥
    Guest

    Re: How does whole-disk encryption work?

    On Tue, 05 Jan 2010 15:02:57 +0100, Frank Merlott wrote:

    > I do not trust Compusec because I read somewhere on their site that they
    > could reset the password.


    Cabernet, Cabernet, engage brain pre-typing.
    --
    A fireside chat not with Ari!
    http://tr.im/holj
    Motto: Live To Spooge It!

  15. #15
    Prof Wonmug
    Guest

    Re: How does whole-disk encryption work?

    On Wed, 06 Jan 2010 08:14:45 -0600, Regis <ordsec@gmail.org> wrote:

    >Regis <ordsec@gmail.org> writes:
    >
    >> Prof Wonmug <wonmug@e.mcc> writes:
    >>
    >>> On Tue, 05 Jan 2010 10:26:38 -0600, Regis <ordsec@gmail.org> wrote:
    >>>
    >>>>Prof Wonmug <wonmug@e.mcc> writes:
    >>>>
    >>>>> I use Carbonite for backup. It does it continually. Would the files
    >>>>> that go to Carbonite for backup be encrypted or clear?
    >>>>
    >>>>If Carbonite stores to a volume or disk that is not encrypted, the
    >>>>backup would be unencrypted. If carbonite is backing up to a volume
    >>>>or disk that is under the management of the disk encryption product,
    >>>>the files would be encrypted.
    >>>
    >>> Carbonite backs up over the Internet to their server. I'm wondering if
    >>> the type of reads they use access the data before or after decryption.

    >>
    >> Almost certainly after encryption,

    >
    >doh. s/encryption/decryption/ Sorry for the possibly confusing
    >typo.


    I thought that's what you meant, but thansk for the clarification.

    >> therefore, what's backed up on
    >> carbonite's server is your original unecnrypted file (assumably
    >> encrypted using whatever encryption their client uses when sending
    >> it).
    >>
    >> Remember, full disk encryption is transparent to apps, to assuming
    >> carbonite has a software client that runs on your machine, carbonite
    >> will make some api call to read a file from teh OS, the full disk
    >> encryption software is shimmed into the operating system making that
    >> call look very normal to carbonite's client, the os reads the
    >> encrypted stuff off the disk, the full disk encryption software's shim
    >> decrypts it, hands it off to the carbonite client unencrypted, whereby
    >> I imagine carbonite's client re-encrypts it in whatever way carbonite
    >> uses, then sends it off to carbonites server.
    >>
    >> In short, Carbonite will behave exactly as it does on a system without
    >> full disk encryption.


    On the other hand, if I encrypt individual folders or files, then
    Carbonite would see them in their encrypted form?

  16. #16
    Regis
    Guest

    Re: How does whole-disk encryption work?

    Prof Wonmug <wonmug@e.mcc> writes:

    >>> In short, Carbonite will behave exactly as it does on a system without
    >>> full disk encryption.

    >
    > On the other hand, if I encrypt individual folders or files, then
    > Carbonite would see them in their encrypted form?


    Heh. We may be running in circles.

    But I *think* I can answer yes, provided you mean "If I individually
    encrypt indivudual files/folders with gpg, or an encrypted zip
    program, or whatever, that file will look to carbonite as encrypted
    (in the format you specifically encrypted that individual file or
    folder) regardless of whether you're running full disk encryption or
    not."

    Full disk encryption being implmented or not won't change how
    Carbonite or any other program running on that operating system sees
    the files.






  17. #17
    noauth
    Guest

    Re: How does whole-disk encryption work?

    On Tue, 02 Feb 2010 20:44:27 -0500, T Pagano <not.valid@address.net> wrote:

    >On Mon, 1 Feb 2010 16:11:03 +0100 (CET), noauth
    ><anon@remailer.gabrix.ath.cx> wrote:
    >
    >>I'd like to use TrueCrypt, but I am unable to make a Bart PE rescue
    >>disk. Too many errors and too complicated. I hardly understand the
    >>instructions.
    >>
    >>Somewhere I heard that the Acronis Rescue Disk would suffice in the
    >>event something went south with my system on an encrypted TrueCrypt
    >>disk. Is this correct?
    >>
    >>I'm using XP Pro with SP3, which is totally up to date with MS >>updates.
    >>
    >>I certainly don't want to risk encrypting my drive without a rescue disk.
    >>
    >>Any TrueCrypt users in here who might know the answer?

    >
    >I'm not sure what help the Acronis Rescue Disk would be if the
    >encrypted hard drive won't, for example, boot. Acronis has no means
    >of decrypting any "working" portion of the file structure.
    >
    >If you were to create an image of your TrueCrypt encrypted hard drive
    >while it is stable and working with Acronis then you could use the
    >Acronis Rescue Disk to copy the good image over one that may have gone
    >bad. Making an image of an encrypted hard drive requires that you
    >use the sector-by-sector method WITHOUT compression. Any compression
    >on an encrypted image makes the image worthless.
    >
    >This is farily straight forward with Acronis. Obviously this requires
    >a back up media at least as large as the computer hard disk.
    >
    >Then if your encrypted hard drive stops working you can use the
    >Acronis rescue disk with the backup image to recover to a working
    >system. This requires that you make images at regular intervals so
    >that recovering from a bad system brings you back to a system that is
    >not too old.
    >
    >Regards,


    That is what I thought I had read awhile back in one of the forums
    dealing with the subject. I just wanted to make sure I was
    understanding it correctly.

    Now, a few more questions:

    1. What exactly does "sector-by-sector" mean? If I save the image
    without any compression, will that accomplish this "sector-by-sector" save?

    2. When I make my normal incremental saves with Acronis, it uses a
    separate partition it creates called the 'Secure Zone' on the C: drive.
    It does not 'image' the *entire* drive, only the system and the file
    data. Now, I take it that TrueCrypt encrypts the *entire* C: drive,
    even if half the drive space is empty. Therefore, if I have a 500Gb
    drive, I must have the backup at least as large as the C: drive. Do I
    have this correct?

    3. I have four outboard USB connected hard drives. If I add another
    drive the size of the present C: drive - USB connected, will that be
    okay to use for saving the Acronis image of the C: TrueCrypt drive?

    Thank you for answering. All this is a bit over my head, but if my above
    assumptions are true, I guess I will give it a go.

    Thanks again. Your answering is much appreciated.











Similar Threads

  1. Does WPA and WPA2 wireless encryption work on Vista?
    By void.no.spam.com@gmail.com in forum ms.public.windows.networking.wireless
    Replies: 13
    Last Post: 11-30-08, 03:00 PM
  2. WEP Encryption - one laptop does not work with it
    By zillah in forum Wireless Networks & Routers
    Replies: 1
    Last Post: 07-28-08, 03:11 PM
  3. Cold boot attacks on disk encryption
    By MadDoctor in forum Network Security
    Replies: 4
    Last Post: 03-14-08, 11:29 AM
  4. work, how far is too far?
    By RoscoPColtrane in forum General Discussion Board
    Replies: 14
    Last Post: 10-02-07, 07:01 PM
  5. Work to home networking...
    By naasirr in forum Networking Forum
    Replies: 6
    Last Post: 06-10-07, 01:52 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •