Truecrypt 5.0 Released (now with system partition encryption)

http://www.truecrypt.org/

Regards,

nemo_outis wrote:
> http://www.truecrypt.org/
>
> Regards,

Anyone tried it? Is it whole disk encryption like PGP whole disk encryption?

Merk <merk@dont.spam> wrote in
news:47aa3faf$0$47180$892e0abb@auth.newsreader.oct anews.com:

> nemo_outis wrote:
>> http://www.truecrypt.org/
>>
>> Regards,
>
> Anyone tried it? Is it whole disk encryption like PGP whole disk
> encryption?

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

Regards,

Merk wrote:
> nemo_outis wrote:
>> http://www.truecrypt.org/
>>
>> Regards,
>
> Anyone tried it? Is it whole disk encryption like PGP whole disk
> encryption?
Yes, everything not is ram is encrypted.

Merk wrote:

> nemo_outis wrote:
>> http://www.truecrypt.org/
>>
>> Regards,
>
> Anyone tried it?


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.

> Is it whole disk encryption like PGP whole disk encryption?


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

nospamatall wrote:

> Merk wrote:
>> nemo_outis wrote:
>>> http://www.truecrypt.org/
>>>
>>> Regards,
>> Anyone tried it? Is it whole disk encryption like PGP whole disk
>> encryption?
> Yes, everything not is ram is encrypted.


Everything except the boot loader.

nospamatall wrote:

> Merk wrote:
> > nemo_outis wrote:
> >> http://www.truecrypt.org/
> >>
> >> Regards,
> >
> > Anyone tried it? Is it whole disk encryption like PGP whole disk
> > encryption?
> Yes, everything not is ram is encrypted.

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.

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

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 wrote:
>> 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.
>
> 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.
>
>
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?

Andy

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

Then if you see a difference, can you explain what the difference is?
That would answer your question at the same time.

nospamatall <nospamatall@iol.ie> wrote in news:foe450$6bv$1@aioe.org:

> Casper wrote:
>>> 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.
>>
>> 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.
>>
>>
> 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?
>
> Andy


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
above.

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

Regards,

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.

On Thu, 07 Feb 2008 00:53:41 +0100, Sebastian G. wrote:

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

Not to look a gift horse but why have they not fixed this?
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

nospamatall wrote:

> Casper wrote:
> >> 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.
> >
> > 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.
> >
> >
> 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?

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
possible.

Has anyone played with this yet? I may have to hook a monitor up to
an old machine. ;)


>
> Andy

Anonymous <xor@hermetix.org> wrote in
news:6a650a93ad6fcd3de594d5b2c71689f6@hermetix.org :

> nospamatall wrote:
>
>> Casper wrote:
>> >> 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.
>> >
>> > 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.
>> >
>> >
>> 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?
>
> 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
> possible.
>
> Has anyone played with this yet? I may have to hook a monitor up to
> an old machine. ;)
>
>
>>
>> Andy

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.

Regards,

nemo_outis wrote:

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

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.

*shrug*

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].

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

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.

[1] http://www.linux.com/base/ldp/howto/...roduction.html

[2] http://en.wikipedia.org/wiki/Encrypt..._storage_stack

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
https://www.mixmaster.it

Cyberiade.it Anonymous Remailer wrote:

> nospamatall wrote:
>
>> Merk wrote:
>>> nemo_outis wrote:
>>>> http://www.truecrypt.org/
>>>>
>>>> Regards,
>>> Anyone tried it? Is it whole disk encryption like PGP whole disk
>>> encryption?
>> Yes, everything not is ram is encrypted.
>
> 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.

Bullshit. You can encrypt the whole disc as well as single partitions.

Ari wrote:

> On Thu, 07 Feb 2008 00:53:41 +0100, Sebastian G. wrote:
>
>> 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.
>
> Not to look a gift horse but why have they not fixed this?


Good question. The last bug is reported about two month ago got only fixed
in version 5.0.

Ari wrote:

> On Thu, 07 Feb 2008 00:53:41 +0100, Sebastian G. wrote:
>
> > 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.
>
> Not to look a gift horse but why have they not fixed this?

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

Sebastian G. wrote:

> Cyberiade.it Anonymous Remailer wrote:
>
> > nospamatall wrote:
> >
> >> Merk wrote:
> >>> nemo_outis wrote:
> >>>> http://www.truecrypt.org/
> >>>>
> >>>> Regards,
> >>> Anyone tried it? Is it whole disk encryption like PGP whole
> >>> disk encryption?
> >> Yes, everything not is ram is encrypted.
> >
> > 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.
>
> Bullshit. You can encrypt the whole disc as well as single
> partitions.

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.

Sebastian G. wrote:

> Merk wrote:
>
> > nemo_outis wrote:
> >> http://www.truecrypt.org/
> >>
> >> Regards,
> >
> > Anyone tried it?
>
>
> 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.

Actually, on Linux I think this is fixed. You have to authenticate as
the "owner" of a volume before giving any system passwords necessary
for mounting that volume. It use to be the other way around.

>
> > Is it whole disk encryption like PGP whole disk encryption?
>
>
> Nah, it also allows for some kinds of dual boot configurations. And it
> compiles with much less changes. And it's far more lightweight.

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
https://www.mixmaster.it

nemo_outis wrote:

> nospamatall <nospamatall@iol.ie> wrote in news:foe450$6bv$1@aioe.org:
>
> > Casper wrote:
> >>> 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.
> >>
> >> 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.
> >>
> >>
> > 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?
> >
> > Andy
>
>
> The entire disk IS encrypted, with the exception of the boot stub on
> track 0.

Tell you what, why don't you go right ahead and shrink your main
bootable partition on your first hard drive and create another
partition on that drive (if you don't have one there already) and then
use Truecrypt to encrypt that entire drive as a single device so the
entire disk IS encrypted. Let us know how that works out for you.

Hope you have backups. ;)

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

Bah! Dozens of things move/alter the partition table Nemo, for all
sorts of reasons.

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

That sounds like a straw grab. And in some cases like someone stealing
your 'puter it's actually a GOOD thing. It's your encryption software
keeping your data out of the hands of a thief in a real permanent way.

If you're using WD encryption and ignore some utility run from a boot
floppy or whatever telling you that it doesn't recognize your drive and
something bad happens I'd call that PEBKAC. If someone else does it you
either have a lack of communication, or a lack of physical security and
the software is covering your ass. :)

>
> 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
> above.

You may not see it as a serious threat, but others are free to disagree
with that opinion. Myself included. In the context of these groups and
recent discussions we've been having about things like RIPA and forced
divulging of passwords, knowing that you need two or more passwords to
get at everything rather than one is a DISTINCT advantage for anyone
bringing the weight of that law to bear against you.

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

Yeah, nobody's saying anything different. In fact nobody's even talking
about that aspect of WD/OTFE encryption Nemo. Why are you? :)

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

Doesn't Truecrypt have a built in mechanism for doing just that? I
think if you read the docs you see something about rescue CD's. ;)

>
> Regards,
>
> 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.

If you knew you were wrong, then why did you make the post?

Casper wrote:

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

Actually, in this case the two things are the same if you're talking
about being able to access your boot partition. That's what the
pre-boot authentication does... set up OTFE access for that drive. It
absolutely *is* encrypted, and looks like random data to anyone with a
LiveCD or whatever.

George Orwell <nobody@mixmaster.it> wrote in
news:d7ac7fb60c39b076fbe85e54bf4ba496@mixmaster.it :

Ah, the first of the whiners and cavillers has arrived. ...with a
farrago of nonsense. ...just as I predicted.


> nemo_outis wrote:
>
>> The entire disk IS encrypted, with the exception of the boot stub
>> on track 0.
>
> No, it's not. If you have two partitions and encrypt only the
> "system" partition the other isn't touched.

Are you usually this thick? Yes, even though you have a whole-disk
encryption program you can choose not to encrypt some partitions - or any
of them for that matter. However, choosing not to use the program's
capability for whole-disk encryption doesn't make it one whit less a
whole-disk encryption program.

As for a boot drive's partition table, some full HD OTFE programs may
encrypt it, while others may not - just as I said. For instance,
Bestcrypt Volume Encryption (one of the better commercial full-HD OTFE
programs) does NOT encrypt the partiton table on a fully encrypted hard
drive - I have just confirmed this with a number of partition managers
(using Hiren v9.3).

Why? Because encrypted partition tables are just asking for trouble from
some program that doesn't recognize that the disk is not trashed (i.e.,
one that misinterprets an encrypted partition table as a corrupted one).

Just as I said.

The benefit from encrypting the partition table? None!

It does not hide the fact that you are using encryption - that's already
instantly discernible by the presence of the encryption programs's
unencrypted executable stub code on track 0.

As for an unencrypted partition table disclosing info, that trivial info
is useless for decrypting the contents of the partitions or even
inferring the nature of what is contained in them.

As for Truecrypt supposedly not being a whole-disk encryption program,
that's just plain wrong. With the release of Version 5 Truecrypt is now
a full-fledged whole-disk encryption program, capable of encrypting any
or all of the partitions on any of the hard drives in a system, including
the boot/system one. Of course, Truecrypt does have an unencrypted stub
on track zero - as do ALL other whole-disk OTFE encryption programs.

Just as I said.

....additional rambling nonsense mercifully snipped...

Regards,

Nomen Nescio <nobody@dizum.com> wrote in
news:8bfad53b8d4b69cd8d27311d874867f6@dizum.com:

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

> Tell you what, why don't you go right ahead and shrink your main
> bootable partition on your first hard drive and create another
> partition on that drive (if you don't have one there already) and then
> use Truecrypt to encrypt that entire drive as a single device so the
> entire disk IS encrypted. Let us know how that works out for you.
>
> Hope you have backups. ;)

You really are a whining caviller. However, lest others be misled, I will
explain why I am 100% correct.

You see, the space on a HD, as conventionally set up, consists entirely of
the following: the boot track and one or more partitions. (This excludes
the rare cases where there is unallocated unpartitioned space on the drive,
and arcana such as the HPA and manufacturer's reserved space).

So, if you encrypt all partitions on such a drive (as Truecrypt v5 now
allows you to do, even if it is the boot/system drive) you have encrypted
the **whole drive** - with the exception, of course, of the small
unencrypted bootstub info on track 0 - just as with ALL other whole-disk HD
OTFE encryption programs.

Just as I said.

Regards,

George Orwell wrote:


>> 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.
>
> Actually, on Linux I think this is fixed. You have to authenticate as
> the "owner" of a volume before giving any system passwords necessary
> for mounting that volume. It use to be the other way around.


Your speculation is going into the wrong direction. The undisclosed
privilege escalation I'm talking about requires only to run a specially
crafted program with non-root privileges by a logged-on user (which might
potentially be compromised). The result is that the program gains root
privileges.

Indeed, the attack works quite well if the malicious program uses
TrueCrypt's official code to create a fresh file container volume without
caring for its content.

nemo_outis wrote:


> You see, the space on a HD, as conventionally set up, consists entirely of
> the following: the boot track and one or more partitions. (This excludes
> the rare cases where there is unallocated unpartitioned space on the drive,
> and arcana such as the HPA and manufacturer's reserved space).
>
> So, if you encrypt all partitions on such a drive (as Truecrypt v5 now
> allows you to do, even if it is the boot/system drive) you have encrypted
> the **whole drive** - with the exception, of course, of the small
> unencrypted bootstub info on track 0 - just as with ALL other whole-disk HD
> OTFE encryption programs.


If you're not using the pre-boot stuff, then TrueCrypt can encrypt the
entire volume including the MBR with its partition table.

"Sebastian G." <seppi@seppig.de> wrote in
news:610sj2F1qodjmU2@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> You see, the space on a HD, as conventionally set up, consists
>> entirely of the following: the boot track and one or more partitions.
>> (This excludes the rare cases where there is unallocated
>> unpartitioned space on the drive, and arcana such as the HPA and
>> manufacturer's reserved space).
>>
>> So, if you encrypt all partitions on such a drive (as Truecrypt v5
>> now allows you to do, even if it is the boot/system drive) you have
>> encrypted the **whole drive** - with the exception, of course, of the
>> small unencrypted bootstub info on track 0 - just as with ALL other
>> whole-disk HD OTFE encryption programs.
>
>
> If you're not using the pre-boot stuff, then TrueCrypt can encrypt the
> entire volume including the MBR with its partition table.

There must - necessarily! - be a small amount of unencrypted code on the
boot/system volume. This is invariably located on track 0.

Regards,

nemo_outis wrote:


>>> So, if you encrypt all partitions on such a drive (as Truecrypt v5
>>> now allows you to do, even if it is the boot/system drive) you have
>>> encrypted the **whole drive** - with the exception, of course, of the
>>> small unencrypted bootstub info on track 0 - just as with ALL other
>>> whole-disk HD OTFE encryption programs.
>>
>> If you're not using the pre-boot stuff, then TrueCrypt can encrypt the

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>> entire volume including the MBR with its partition table.
>
> There must - necessarily! - be a small amount of unencrypted code on the
> boot/system volume. This is invariably located on track 0.


I underlined you something. Full disk encryption doesn't necessarily imply
that the encrypted volume is a boot/system volume.

"Sebastian G." <seppi@seppig.de> wrote in
news:610vsoF1rnd8cU1@mid.dfncis.de:


> I underlined you something. Full disk encryption doesn't necessarily
> imply that the encrypted volume is a boot/system volume.


This is true albeit somewhat banal. Any Windows OTFE program capable of
encrypting partitions has long been able to encrypt all the partitions on
all drives - with the sole exception of the boot partition on the system
drive. That was the last hurdle for Truecrypt, one which v5 has now
cleared.

Truecrypt (for v5 as for previous versions) represents in its documentation
that it does NOT change in any way (much less encrypt) the partition table
on a drive on which Truecrypt partitions reside (i.e., does not encrypt it
and has no special Truecrypt signature byte). I heven't checked whether
this is indeed so in all cases.

Regards,

nemo_outis wrote:


> Truecrypt (for v5 as for previous versions) represents in its documentation
> that it does NOT change in any way (much less encrypt) the partition table
> on a drive on which Truecrypt partitions reside (i.e., does not encrypt it
> and has no special Truecrypt signature byte). I heven't checked whether
> this is indeed so in all cases.


Maybe this statement was confusing: TrueCrypt can encrypt entire drives and
mount it as a raw volume. Within this volume, you can create a partition
table and associated partitions, which may or may not be additionally
encrypted, or you may put there whatever you want.

An attacker seeing the raw encrypted volume will only perceive random
garbage at the place where the partition table would reside, and indeed one
must be very careful to not run any partitioning tools with admin privileges
while the raw volume is not mounted.