Unclear choice encrypting a non system drive with TrueCrypt

Discussion in 'privacy technology' started by Tekhne, May 28, 2014.

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

    Tekhne Registered Member

    Joined:
    May 23, 2014
    Posts:
    19
    So, there is a non system SSD I want to encrypt. But in the create new volume wizard where I am to select device, the device shows up as well as it's partitions. After selecting the device I'm prompted with this dialog/info box, whatever I should call it:

    http://i.imgur.com/CTDl7Fm.jpg
    And so, I find myself in the ever bewildered jungle that sometimes softwares may leave us by giving us a bit of ambiguity.

    So.
    1) What are the pro's and cons to encrypting the whole device vs the partition ?
    I heard of header corruption when encrypting a whole device(though I don't understand how or why, or if that is relevant or just paranoia, since I thought computers was supposed to be objective and predictable) but only in relation to external devices, hence I have made a note to myself to always encrypt external devices on the partition level instead of the whole drive, but does it apply to internal devices as well...?

    2) What is this info trying to say in what context when it mentions "formatting a device that contains partitions might cause system instability and/or data corruption." IF your going to format the device, the any data will be lost, so it's not making it very clear to me what data it is even talking about here. Can anyone make sense of it and explain it so it's easy to fathom ?

    2) An other small thing that comes to my mind with these SSD's(or maybe it applies to all harddrives) is that, I thought that small partition that is automatically created(usually always one on just a few hundred MB's even though we don't make it our selfs, I've tried deleting them in the past but they always reappear after formating iirc) is needed for it's normal operational use in some way. And that by deleting all partitions, and encrypting it, may someway perhaps cause adverse effects.

    Some additional background knowledge if it might be relevant:
    The device is empty and new.
    I don't intend to have multiple partitions. i.e. the whole space of it is intended to be encrypted, whether it is on a partition level or device level.
     
    Last edited: May 28, 2014
  2. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    164,067
    Location:
    Texas
  3. Tekhne

    Tekhne Registered Member

    Joined:
    May 23, 2014
    Posts:
    19
    Thanks @ronjor . I took a good look at that. Though it didn't really clear the question. It was helpful.

    @dantz who is in answering in that other thread you linked to gives insightful answers, but first gives me one impression in favor of the one over the other:
    But then right after, cancels it out and puts me back to where I started:
    It seems then that both options have the same issue no matter what you choose then ? Though I never encountered it myself on my own encrypted drive that is to be replaced. (And I can't even remember what option I choose back then when I encrypted that one)

    Further more it doesn't address my other concerns like:
    1) is the header corruption issue equally relevant to internal drives and in the same way as they are to external ?
    Or points 2) & 3) in my OP.

    He also doesn't specify clearly some of the things he mentions like:
    Which only further begs the questions asked, if this applies equally to external and internal drives, (lest one must disconnect a internal drive during a windows reinstall...) and whether or not it applies to both partition and device level encryption.
    i.e. the link talks about similar and related stuff but without giving a clear answer.
     
    Last edited: May 28, 2014
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.