Seeking list of common mistakes when using encryption products

Discussion in 'encryption problems' started by wilder7500, Jan 5, 2014.

  1. wilder7500

    wilder7500 Registered Member

    Joined:
    Dec 30, 2013
    Posts:
    58
    Location:
    USA
    It would be nice to have a condensed list of the common mistakes users make when when using Truecrypt. A paragraph form separated by a line would make it easier to read. Any thoughts?

    *EDIT* List so far, some paragraphs may overlap:



    1. disk repartitioning (which is NEVER a good idea in the presence of an encrypted partition),

    2. reinstalling or upgrading the OS while an encrypted partition is present or connected,

    3. deleting a container file by mistake,

    4. formatting the wrong partition by mistake,

    5. allowing Windows to format an encrypted partition or initialize an encrypted disk (which under certain conditions can occur even without prompting),

    6. accidentally overwriting or otherwise losing the partition table,

    7. forgetting their password,

    8. changing keyboards or keyboard layouts and then discovering that their password doesn't work anymore,

    9. failure to back up their headers,

    10. failure to back up their data,

    11. editing or deleting their keyfile (if used)

    12. failure to back up their keyfile (if used),

    13. failure to back up their keyfile path (if used) or even understand the difference between a keypath and a keyfile,

    14. altering any files or folders in the keyfile path,

    15. failure to back up their rescue disk (for system encryption only),

    16. failure to recognize that encrypted data is more vulnerable than plaintext data, and finally,

    17.behaving cluelessly. (Yes, "behaving cluelessly" in the presence of encrypted data is a good way to lose it.)

    18. Not having/making a reliable backup BEFORE using TrueCrypt. This actually applies to any use of a computer. Numerous threads screaming of data loss when a simple and reliable backup would have solved the problem easily.

    19. Not RETAINING a volume header backup on removable media. Screaming threads one after another because the user didn't make a backup header (also rescue disk for system encrytion) and actually keep it where they could use it. Its a little 128K file but its a life saver.

    20. If you're using the hidden volume feature then a comparison of two or more different copies of the same volume could possibly reveal that.

    21. comparison would also most likely show that your volume is actually in use, negating any false claims on your part that it is merely "random data from a disk wipe" or something of the sort.

    22. (only for users with very high threat models): Being able to compare the differences between the two containers would theoretically aid cryptanalysis (although I've never heard of anybody actually succeeding in breaking into a volume that way).
     
    Last edited: Jan 7, 2014
  2. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    994
    Location:
    Hawaii
    Re: Seeking list of common mistakes when using Trucrypt

    Well, here's a partial list. I copied it from one of my previous posts. I realize that it's incomplete and it could use a lot more detail, but it's a start:
    And I'm sure that others here would add "failure to read and understand the user's guide".

    The entire list, and more, ought to be expanded upon (with more detailed explanations), compiled into a list of "Don'ts" and then included in the user guide (like that's ever going to happen).
     
  3. Page42

    Page42 Registered Member

    Joined:
    Jun 18, 2007
    Posts:
    5,829
    Location:
    Last Breath Farm
    Re: Seeking list of common mistakes when using Trucrypt

    Great thread. :thumb:
    Can screwing up TrueCrypt result in hosing one's computer to the point of rendering it unbootable, or does screwing up, at worst, result in mere data loss?
     
  4. wilder7500

    wilder7500 Registered Member

    Joined:
    Dec 30, 2013
    Posts:
    58
    Location:
    USA
    Re: Seeking list of common mistakes when using Trucrypt

    Thanks very helpful.
     
  5. zapjb

    zapjb Registered Member

    Joined:
    Nov 15, 2005
    Posts:
    3,526
    Location:
    USA - Back in a real State in time for a real Pres
    Re: Seeking list of common mistakes when using Trucrypt

    Definitely to the point of unbootabletability. :)
     
  6. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    1,599
    Re: Seeking list of common mistakes when using Trucrypt

    After years with this product and spending countless hours participating on several forums I will condense it down to the two I see most often:

    1. Not having/making a reliable backup BEFORE using TrueCrypt. This actually applies to any use of a computer. Numerous threads screaming of data loss when a simple and reliable backup would have solved the problem easily.

    2. Not RETAINING a volume header backup on removable media. Screaming threads one after another because the user didn't make a backup header (also rescue disk for system encrytion) and actually keep it where they could use it. Its a little 128K file but its a life saver.

    Idiot factor: I am not counting this because its so stupid. I am just mentioning it for when you read around and see it happen time after time. What am I talking about? Users that literally proceed with full encryption/deployment and they have never even attempted to read the users manual.
     
  7. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,516
    Re: Seeking list of common mistakes when using Trucrypt

    I have hot imaging of unecrypted OS with AX64 Time Machine onto my system favourite volume, and cold imaging of encrypted OS with Parted Magic's Clonezilla onto an unencrypted external drive.

    My Truecrypt Rescue ISO is stored on the external as well. Don't think any more is necessary.
     
  8. chiraldude

    chiraldude Registered Member

    Joined:
    Jul 3, 2010
    Posts:
    157
    Re: Seeking list of common mistakes when using Trucrypt

    Rendering your system unbootable will only happen if using system encryption. If you only use file hosted or non-system disks/partitions the worst that will happen is data loss.
     
  9. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,275
    Location:
    Here, There and Everywhere
    Re: Seeking list of common mistakes when using Trucrypt

    I'll add one. Theoretically, and/or/if you are facing an expert adversary, you should not clone TC volumes (containers).
     
  10. wilder7500

    wilder7500 Registered Member

    Joined:
    Dec 30, 2013
    Posts:
    58
    Location:
    USA
    Re: Seeking list of common mistakes when using Trucrypt

    Could you explain why?
     
  11. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    994
    Location:
    Hawaii
    Re: Seeking list of common mistakes when using Trucrypt

    1) If you're using the hidden volume feature then a comparison of two or more different copies of the same volume could possibly reveal that.

    2) A comparison would also most likely show that your volume is actually in use, negating any false claims on your part that it is merely "random data from a disk wipe" or something of the sort.

    3) (only for users with very high threat models): Being able to compare the differences between the two containers would theoretically aid cryptanalysis (although I've never heard of anybody actually succeeding in breaking into a volume that way).

    As for myself, I make multiple copies of my container files all the time for backup purposes. I have no concerns with any of the above scenarios, all of which I consider to be irrelevant to my situation. I'd much rather have the good backups.
     
  12. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    994
    Location:
    Hawaii
    Re: Seeking list of common mistakes when using Trucrypt

    I sometimes consider TrueCrypt to be an agent of natural selection masquerading as an encryption program.
     
  13. Paranoid Eye

    Paranoid Eye Registered Member

    Joined:
    Dec 15, 2013
    Posts:
    174
    Location:
    io
    Re: Seeking list of common mistakes when using Trucrypt


    Yeah same here I don't think I have heard any situations where they have really checked into the drive and could prove 2 hdds are really encrypted and contain large data blocks meaning hidden data, I hear the term many times but otherwise surely its just a hdd with random filled data which you just used random wipe mode from dariks nuke and boot cd.....

    Would always advise making it hidden so you can use the outer password to reveal normal important docs still....
     
  14. Larm

    Larm Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    10
    Re: Seeking list of common mistakes when using Trucrypt

    Full disk (system) encryption (FDE) is not enough!

    I've seen several guides recommending FDE and giving the impression that it's a complete solution.

    In reality, using FDE means that encryption keys are stored in the memory unencrypted all the time (otherwise the OS couldn't access the disk). This is especially dangerous for laptops: when you use sleep or hibernation, keys will remain in the memory or are written to the disk. Therefore, anyone who steals your laptop in this state can easily bypass the FDE.

    The correct way is to use separate Truecrypt containers for sensitive files in addition to the FDE. These containers MUST be unmounted before leaving the computer unattended or before using sleep/hibernation.
     
  15. zorkling

    zorkling Registered Member

    Joined:
    Jan 11, 2014
    Posts:
    40
    Location:
    U.S.
    What about defragmentation or disk cleanup on a mounted volume? I think that was my mistake.
     
  16. Paranoid Eye

    Paranoid Eye Registered Member

    Joined:
    Dec 15, 2013
    Posts:
    174
    Location:
    io
    Agreed with Larm was going to add leaving the Pc while your container or volume is left unencrypted.

    Hibernation and page file systems can also save passwords and data and should be switched off for better security also.
     
  17. crawfish

    crawfish Registered Member

    Joined:
    Jul 2, 2014
    Posts:
    24
    Hibernation files and pagefiles are not a problem when using FDE as long as they are encrypted like everything else.

    Hibernation mode is not a problem, because the computer is not powered on, not even the memory.

    Sleep mode is of course an issue, as the drives will typically still be mounted when you resume from sleep. That's why I have my laptop hibernate automatically after a few hours in sleep mode, just in case I forget about it. The desktop is typically not going to be a problem, because the crackhead who breaks into my home isn't going to sit down and try to crack my Windows password; he's just going to steal it without thinking about maintaining power, unlike George and his Frogger high score.
     
  18. blainefry

    blainefry Registered Member

    Joined:
    Jan 25, 2014
    Posts:
    165
    That should not be an issue. The TC documentation explicitly states in multiple places that you defrag volumes...

    http://andryou.com/truecrypt/faq.php


    While the part about keys and sensitive files potentially being available in RAM is true, the part about hibernation is not.

    By definition, FDE means the "full disk" is encrypted...meaning everything, including the paging file, hibernation file, etc. (assuming we're talking about the disk the operating system resides on, which is where those kinds of files are usually stored.) That's the whole point.

    FDE on the system disk is a solution to protecting against keys and data stored in memory like that, provided the RAM is wiped or powered off (which is what happens during hibernation.) Just have a look at the TC documentation. It explicitly contradicts exactly what Larm is claiming:

    "When the computer hibernates, data are encrypted on the fly before they are written to the hibernation file."

    If you have some kind of proof that this isn't true, I'm sure the crypto world would love to hear about it.

    Otherwise, hibernating the computer with FDE on the system drive is perfectly fine. The only issue is if you need plausible deniability. In that case there's a few more precautions you need to take, and you'll need a hidden operating system.

    But if you're going to insist on using encrypted containers for everything and dismounting them all the time, then there's no need for FDE...especially if you're assuming an adversary is going to gain access to your mounted system. FDE provides absolutely zero benefit in that scenario.

    So to reiterate:

    If an adversary gains access to your system while an encrypted volume (of any kind) is mounted, obviously you're screwed.

    If you have time to dismount encrypted containers, then you should alternatively have time to power down the system or hibernate it. (Granted, the latter two can take longer than dismounting, so if we're talking about a "they're breaking in the door" scenario where literally seconds matter, you may gain some benefit to using containers or non-system devices/partitions over system encryption, but again, if we're assuming you can't clear the RAM, then there's no point to system FDE anyway.)

    So either you assume you can't afford the extra few seconds it will take to power off or hibernate, and don't bother with system FDE, or you maintain a habit of doing one of those things when you leave your system, in which case you shouldn't need encrypted containers.

    There is no need to "double up" and use encrypted containers within an encrypted system volume. Certainly not as some way to protect against data leaks.
     
  19. blainefry

    blainefry Registered Member

    Joined:
    Jan 25, 2014
    Posts:
    165
    LOL
     
  20. Randcal

    Randcal Registered Member

    Joined:
    May 29, 2014
    Posts:
    76
    It's actually worse than that. If someone is busting down your door, it's very possible you'll end up in an extortion situation...in which case having your volumes dismounted will not help you, because there will likely be data references from the encrypted containers (e.g. filenames, file paths, etc...if not files themselves) stored in RAM or on the system partition. The adversaries would then have proof the files exist and move to force you to decrypt the containers.

    (This would likely happen even in US courts because if they have encrypted containers (which are easily identifiable) and filenames and file paths that don't exist on the unencrypted portions of the drive, it's a pretty safe bet they're in the containers and therefore the existence of the files is what the courts call a "foregone conclusion", and they will most likely force you to decrypt the drive.)

    We talked about this in these two threads:

    "Depends on the court"

    Massachusetts high court orders suspect to decrypt his computers

    This is why I keep reiterating how important plausible deniability is. There are fewer scenarios than people think where encryption alone will protect you.
     
Loading...