Encryption failure

Discussion in 'privacy technology' started by EdP, Apr 18, 2009.

Thread Status:
Not open for further replies.
  1. EdP

    EdP Registered Member

    Joined:
    Mar 18, 2004
    Posts:
    83
    Reading through forums as well as software User Guides, it appears that there's always a chance of an encrypted volume becoming corrupted. It happened to me several years ago, but because I had a recent backup, I didn't lose too much, but I did lose a few irreplaceable files.

    I don't know what caused the corruption, but I do know it wasn't anything catastrophic such as a drive suddenly going belly-up or a system crash; the password simply would not open the container.

    I'd like to know what can be done to minimize the possibility of this happening again. Are there any guidelines, practices, procedures to follow?

    Thanks
    EdP
     
  2. Warlockz

    Warlockz Registered Member

    Joined:
    Oct 30, 2008
    Posts:
    642
    Yes, you need to get yourself an extra HD, like a 320GB Seagate freeagent go, and store your Backup encrypted container on it, then if your original container fails, you will have your backup to rely on...

    Theirs no such thing as sureproof from procedure, Backups are futile when using any kind of encryption with valuable data!
     
  3. jonw

    jonw Registered Member

    Joined:
    Jan 22, 2009
    Posts:
    83
    Just wondering what can cause a encrypted drive to go bad, the reason I ask is because I have been using encrypted drives for about a year now. I have seen horror story's on here about people loosing there whole drive full of irreplaceable pictures and important files, is there anything besides keeping good backups that I can do to keep this from happening to me?
     
  4. EdP

    EdP Registered Member

    Joined:
    Mar 18, 2004
    Posts:
    83
    Thanks for the quick response, warlockz ...

    I do have a couple of external HDs that I use for backup and which I rely on. However, my question was oriented more to prevention than restoration.
     
  5. markoman

    markoman Registered Member

    Joined:
    Aug 28, 2008
    Posts:
    188
    Backups are your best weapon against data loss. Machines fail, and any machine, at some point, will fail, possibly causing all your data to be lost. This is why you have backups.

    Think about how valuable your data is; what would it mean to lose 1 hour worth of data? What about 4? 12? 24? One week?
    Then decide how much you are ready to lose, and schedule backups every x hours, considering that the bigger x, the more data you are ready to lose.
    Of course, plan regular restore tests...

    Having data encrypted makes it a bit easier (most of the times because of human error) to lose data, but data is at risk anyways, so better backup.
     
  6. EdP

    EdP Registered Member

    Joined:
    Mar 18, 2004
    Posts:
    83
    >most of the times because of human error<
    Such as ...?
     
  7. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Here are some specific examples: If you're using TrueCrypt, doing anything that overwrites a portion of the volume header will often result in a total loss of access and what appears to be a "password failure". This sometimes happens when users mistakenly allow Windows to initialize a fully encrypted drive, or when they run software which is known to write to the area of the disk where the headers are stored. For example, Acronis Disk Director appears to direct Windows to write a 4-byte DiskID to any unrecognized disks without prompting the user, so the user generally has no idea that their encryption header was just ruined, or even how it happened. Certain other types of software are also known to occasionally write to this area. (I believe that certain Adobe products use a copyright protection scheme that has been implicated). In other cases Windows prompts the user whether or not it should initialize an unrecognized disk, and for some reason the user clicks on Yes, which also overwrites a portion of the header of their fully encrypted drive with a 4-byte DiskID.

    Another common mode of failure occurs when a user mistakenly quick-formats an encrypted drive due to a case of mistaken identity. (Since Windows doesn't recognize an unmounted drive, the user is sometimes fooled into thinking it's a blank disk.) When file-hosted volumes are used it's also relatively common for users to mistakenly delete or overwrite their container files during a mental lapse.

    "Hard" failures can also occur, of course, and if a drive happens to lose one of the crucial bits within the volume header then the entire volume can become inaccessible. If the damage occurs to the data area of an encrypted volume then usually only that specific block of data will be affected. However, you can lose the encrypted filesystem if, for example, the MFT or some other critical area is damaged during a hard or soft failure. In cases like this you can usually input your password and access the encrypted volume just fine, but you can't see any files. The solution is to keep data backups, although data-recovery software also might be useful in this case.

    The solution to header damage, if you're using TrueCrypt, is to restore the damaged headers from a header backup. The wise approach, however, is to back up ALL encrypted data, no matter what type of encryption is used, as there many other potential modes of failure, and encrypted data is particularly difficult if not impossible to recover via the normal means.

    The most important thing is for all users to become informed about how their software functions and what can go wrong. The vast majority of what you call "encryption failure" is due to user ignorance and the subsequent screwups.
     
  8. Pleonasm

    Pleonasm Registered Member

    Joined:
    Apr 9, 2007
    Posts:
    1,201
    EdP, I run “CHKDSK /F” on my PGP encrypted virtual volumes, to check and to ensure their integrity. It is good practice to periodically verify the “health” of every disk on your PC, whether encrypted or not.
     
  9. EdP

    EdP Registered Member

    Joined:
    Mar 18, 2004
    Posts:
    83
    Thanks much for the responses.

    If at all possible, I think the wise thing to do is mount the encrypted container and do what needs to be done to its contents and dismount it. Don't frog around with anything else while it's mounted.

    I realize that not everyone can do this because of their unique needs, but I think I may be able to. We'll see.

    Of course I'll always have backups.
     
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    I suppose it can't hurt, but from what I've seen on the TrueCrypt boards the majority of the "Help, I can't access my data" screwups have occurred while the volume was dismounted.
     
Loading...
Thread Status:
Not open for further replies.