Truecrypt 5.0 Released (now with system partition encryption)

Discussion in 'Computer Security' started by nemo_outis, Feb 6, 2008.

  1. nemo_outis

    nemo_outis Guest

    nemo_outis, Feb 6, 2008
    1. Advertisements

  2. nemo_outis

    Merk Guest

    Anyone tried it? Is it whole disk encryption like PGP whole disk encryption?
    Merk, Feb 6, 2008
    1. Advertisements

  3. nemo_outis

    nemo_outis Guest

    I haven't tried it yet but the description suggests it is functionally
    equivalent to PGP Wholedisk, etc.

    nemo_outis, Feb 6, 2008
  4. nemo_outis

    Guest Guest

    Yes, everything not is ram is encrypted.
    Guest, Feb 6, 2008
  5. nemo_outis

    Sebastian G. Guest

    I tried it, and, unlike most other pre-boot stuff, actually worked on my
    trivial test machine.

    However, I found a privilege escalation vulnerability from version 4.3a
    being carried over, so I heavily recommend to avoid using TrueCrypt until
    it's fixed.

    Nah, it also allows for some kinds of dual boot configurations. And it
    compiles with much less changes. And it's far more lightweight.
    Sebastian G., Feb 6, 2008
  6. nemo_outis

    Sebastian G. Guest

    Everything except the boot loader.
    Sebastian G., Feb 6, 2008
  7. No, it's not. With a two partition setup and both encrypted you can
    still see partition information booting from a LiveCD

    It's NOT whole disk encryption. It was never advertised as such.
 Anonymous Remailer, Feb 7, 2008
  8. nemo_outis

    Casper Guest

    No, it's not. With a two partition setup and both encrypted you can
    Thank you for the info, I am glad you understand the difference between
    asking for a password on boot up and having the whole thing encrypted,
    too many people confuse these terms.
    Casper, Feb 7, 2008
  9. nemo_outis

    Guest Guest

    I can see that there is a difference, but why would it be important? If
    the entire disk is encrypted, how could you do anything with it?

    Guest, Feb 7, 2008
  10. nemo_outis

    Casper Guest

    I can see that there is a difference, but why would it be important? If
    Then if you see a difference, can you explain what the difference is?
    That would answer your question at the same time.
    Casper, Feb 7, 2008
  11. nemo_outis

    nemo_outis Guest

    The entire disk IS encrypted, with the exception of the boot stub on
    track 0.

    All full HD OTFE encryption schemes need a small amount of unencrypted
    code to initialize themselves, etc. and this is normally stored on track
    0, with the BIOS doing handoff to the first sector on that track (the
    MBR) during bootup from the HD (assuming it has the system partition).

    Usually only the first sector on that (notionally 63-sector) track is
    non-empty (although there are exceptions) so usually there is no problem
    with the encryption software arrogating the whole track to itself. Most
    do. (Their arrogation of track 0 can cause problems with some
    multi-loaders, etc. which also wish to grab track 0)

    The conventional partition table is also normally stored as part of the
    first sector of track zero (there are some subtle differences for newer
    schemes such as GPT/GUID partitions). While this table could be
    encrypted by full HD OTFE software it is, IMNSHO, bad practice to do so.
    The reason is that other software (as might be used, for instance, by
    someone who does not know that the disk is encrypted) often reads the
    partition table to discern how the disk is used and even whether it is
    trashed and available for (re-)formatting. An encryped partition table
    is just begging for trouble from any use of such software.

    The only information leaked by using an unencrypted (conventional)
    partition table is the start, end, size, type/signature, and "active"
    bit/(drive #) of the (up to) 4 partitions . This is not a serious
    leakage of information and leaving the partition table in plaintext
    (plaintext for a partition table, that is) minimizes the risks noted

    In short, ALL full HD OTFE encryption programs have an unencrypted stub
    on the boot hard drive. Some of them may encrypt the partition table,
    some may not - but the security risks in not encrypting are negligible
    and it minimizes risks from other sources.

    It is generally good practice to back up the entire first track (which
    includes the MBR). In fact, most "emergency recovery disks" for full HD
    OTFE programs do exactly this (and often a bit more as well).


    PS There will be all sorts of wailing and moaning over this post from
    various quibblers, cavillers, and whiners - have many large grains of
    salt handy to deal with their responses.
    nemo_outis, Feb 7, 2008
  12. nemo_outis

    Ari Guest

    Not to look a gift horse but why have they not fixed this?
    Ari, Feb 7, 2008
  13. nemo_outis

    Anonymous Guest

    We were just discussing the issue of plausible deniability, and
    determining if individual encrypted devices/volumes existed at all.
    If you need to hide the fact that certain volumes exist then it
    becomes an issue.

    I haven't tried it out yet, but the nice thing about system
    partition encryption is that you should be able to create a hidden
    volume on a system partition which would be truly invisible to the
    host partition and any OS you have installed there. In theory, the
    choice of passwords at boot time could switch back and forth
    between two completely different and independent operating
    environments. That's an even better alternative to running guest
    operating systems under VMWare for some of us, if it's actually

    Has anyone played with this yet? I may have to hook a monitor up to
    an old machine. ;)
    Anonymous, Feb 7, 2008
  14. nemo_outis

    nemo_outis Guest

    If you use any current scheme of full HD OTFE encryption then the fact
    that you use encryption is necessarily given away. The code in the
    "bootable stub" of the encryption program on track zero will disclose to
    any knowledgeable investigator, not only that you are using full HD
    encryption, but which vendor's. In fact, often just the "signature
    byte" of an (unencrypted) partition table is enough to reveal the
    encryption vendor.

    You could, I suppose overwrite track zero (and the rest of the plaintext
    "bootstub" if it goes beyond track zero) with random garbage between user
    sessions (using a reboot from CD/floppy/USB to run the random overwriting
    program) and then use the "recovery disk" to restore the bootstub info
    when starting another session hours, days, or weeks later. Such a dual
    boot approach (once with floppy/CD/USB to use the restore function of the
    full HD encryption software, and then a second time to invoke it) would
    not be too onerous for the paranoid since the restoration typically only
    involves a few megs.

    I would not do this for plausible deniability reasons (I don't think the
    game is worth the candle) but it could be worthwhile to ensure that no
    one has tampered with the only plaintext code on the drive: the bootstub
    of the full HD encryption program. (Restoration of the few megs would
    presumably take only slightly longer than hash verification, although
    that is an alternative.)

    Overwriting the patrtition table with junk could, however, expose one to
    the risks I discussed in a previous post. But if the partition data is
    preserved (and not overwritten with random junk) then at least the
    "signature byte" of each partition should be changed from any that reveal
    that an encryption scheme was used.

    nemo_outis, Feb 7, 2008
  15. No, it's not. If you have two partitions and encrypt only the
    "system" partition the other isn't touched. If you encrypt both,
    they still exist as independent partitions. Some amount of data
    about each will be stored in the MBR depending on operating system,
    and all the "gotchas" with respect to an OS stashing away
    information about partition/file access and such still exist, even
    for "hidden" volumes on non-system partitions.

    We were just discussing the hows and whys of hiding the fact that
    volumes exist can be significant guy, I'm surprised you can't see
    why to some people this subtle difference would be important.

    As to your "encrypted partition tables are asking for trouble"
    guesswork, that's just pure bunk. All true WD encryption products
    I'm aware of do exactly that, and a lot of other utilities like
    whole disk compressors and certain boot managers perform similar
    functions. So far the net hasn't been flooded with reports of all
    the disasters you seem to think should be occurring.


    Exposed partition tables absolutely are less secure than their
    encrypted cousins, too. One of the first things any cryptanalyst
    who isn't just plodding along doing brute force attacks asks is
    *what* is being encrypted. That's an easy question to answer if
    partition information is laid out at his feet[1].
    It's not quibbling and whining, it's called being accurate. The two
    types of encryption being discussed here don't even function at the
    same layer. Whole disk is "storage layer"[2] encryption and
    Ttruecrypt obviously does business at the file system layer.

    I'm sure you'd like people to think that difference is just mindless
    nit picking because you can't stand being wrong about something,
    but the fact remains that Truecrypt is not, and isn't even marketed
    as, a whole disk encryption product. In fact the only person I've
    seen call it that, is you.



    Il mittente di questo messaggio|The sender address of this
    non corrisponde ad un utente |message is not related to a real
    reale ma all'indirizzo fittizio|person but to a fake address of an
    di un sistema anonimizzatore |anonymous system
    Per maggiori informazioni |For more info
    George Orwell, Feb 7, 2008
  16. nemo_outis

    Sebastian G. Guest

    Bullshit. You can encrypt the whole disc as well as single partitions.
    Sebastian G., Feb 7, 2008
  17. nemo_outis

    Sebastian G. Guest

    Good question. The last bug is reported about two month ago got only fixed
    in version 5.0.
    Sebastian G., Feb 7, 2008
  18. In a similar vein, the Linux version sucks. ;)

    OS encryption (it's not wholedisk) isn't even implemented. That's not a
    huge problem because Linux has native counterparts, but it would have
    been nice.

    There's also a cute new GUI, but you can't get around it as far as I can
    tell. So if you're running Truecrypt on a remote machine via ssh or
    what not, you'd better have GTK installed and X forwarding enabled or
    you're screwed until you downgrade. Reminds me of that damned GnuPG2
    pinentry crap. <grrrrrr>

    They also changed the sequence of passwords, at least on my Debian box
    (the only place I've tried it so far). Threw me off the first time. I
    thought my volumes were no longer compatible. ;)
 Anonymous Remailer, Feb 7, 2008
  19. nemo_outis

    Nomen Nescio Guest

    You should try things before running your mouth. Might save you the
    embarrassment of finding out later that if you do "device level"
    encrypt your system partition it's bye bye system and any other
    partitions you have on that drive. And you can't reinstall without
    blowing away Truecrypt. Your "boot drive" is a brick until you do.

    That's not whole disk encryption by anybody's definition. Even a
    loud mouth know-it-all wannabe's like you I suspect, but acute
    narcissism will prevent you from admitting it.
    Nomen Nescio, Feb 7, 2008
    moparhoLICK is responsible for ALL the kb9rqz, gav, Feb 7, 2008
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.