PDA

View Full Version : Truecrypt 5.0 Released (now with system partition encryption)



Pages : [1] 2 3 4

nemo_outis
02-06-08, 10:49 AM
http://www.truecrypt.org/

Regards,

Merk
02-06-08, 05:16 PM
nemo_outis wrote:
> http://www.truecrypt.org/
>
> Regards,

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

nemo_outis
02-06-08, 05:34 PM
Merk <merk@dont.spam> wrote in
news:47aa3faf$0$47180$892e0abb@auth.newsreader.octanews.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,

nospamatall
02-06-08, 05:51 PM
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.

Sebastian G.
02-06-08, 05:53 PM
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.

Sebastian G.
02-06-08, 05:54 PM
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.

Cyberiade.it Anonymous Remailer
02-06-08, 10:09 PM
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.

Casper
02-06-08, 10:56 PM
> 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.

nospamatall
02-06-08, 11:15 PM
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

Casper
02-06-08, 11:25 PM
> 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.

nemo_outis
02-06-08, 11:48 PM
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.

Ari
02-07-08, 12:10 AM
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

Anonymous
02-07-08, 12:45 AM
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

nemo_outis
02-07-08, 01:17 AM
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,

George Orwell
02-07-08, 01:45 AM
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/Disk-Encryption-HOWTO/introduction.html

[2] http://en.wikipedia.org/wiki/Encryption_layer_in_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

Sebastian G.
02-07-08, 05:09 AM
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.

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

Sebastian G.
02-07-08, 05:12 AM
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.

Cyberiade.it Anonymous Remailer
02-07-08, 09:00 AM
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. ;)

Nomen Nescio
02-07-08, 09:30 AM
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.
>
> ********. 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.

George Orwell
02-07-08, 09:54 AM
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

Nomen Nescio
02-07-08, 10:10 AM
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?

Nomen Nescio
02-07-08, 10:20 AM
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.

nemo_outis
02-07-08, 10:33 AM
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,

nemo_outis
02-07-08, 10:55 AM
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,

Sebastian G.
02-07-08, 11:10 AM
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.

Sebastian G.
02-07-08, 11:14 AM
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.

nemo_outis
02-07-08, 11:23 AM
"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,

Sebastian G.
02-07-08, 12:10 PM
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.

nemo_outis
02-07-08, 12:32 PM
"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,

Sebastian G.
02-07-08, 02:27 PM
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.

Cyberiade.it Anonymous Remailer
02-07-08, 02:33 PM
Sebastian G. wrote:

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

It "can", but that's a destructive process and there's absolutely no
way to bootstrap any operating system that you might install after the
fact.

You guys aren't thinking this through.

nospamatall
02-07-08, 03:22 PM
Anonymous wrote:
> 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 would have thought that this is not an issue with TrueCrypt, because
the hidden partition is within the free space of another encrypted
partition and thus doesn't show up anywhere else?

Phil Carmody
02-07-08, 03:44 PM
Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it> writes:
> Sebastian G. wrote:
>
> > 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.
>
> It "can", but that's a destructive process and there's absolutely no
> way to bootstrap any operating system that you might install after the
> fact.
>
> You guys aren't thinking this through.

Au contraire. Sebastian's thought this through in its
entirety, it's just that you're all taking a long time
to catch up.

Your "that's a destructive process" is either meaningless
or wrong. Your "there's absolutely no way to bootstrap any
operating system" is completely false. Boot of another
medium. Trivial.

_Any_ container for an encrypted file system will break
the contained file system if tampered with. That applies
exactly equally to an entire disk as it does to a single
file sitting within an arbitrary other file system.

Please try to keep up.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Paul Rubin
02-07-08, 03:44 PM
Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it> writes:
> It "can", but that's a destructive process and there's absolutely no
> way to bootstrap any operating system that you might install after the
> fact.
>
> You guys aren't thinking this through.

I don't know anything about truecrypt and haven't been following this
discussion, but I've often wanted to encrypt my laptop's internal hard
drive like that. The only way to boot would be from another drive,
and I'd use a usb pen drive for that purpose.

nospamatall
02-07-08, 03:47 PM
Casper wrote:
>> 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.
>
>
The difference is that the partition info and some other stuff may not
be encrypted. This doesn't answer my question though. Do any data leak
into the non-user partitions? I had heard that some shyster companies
use these partitions for their nefarious 'DRM' so I spose it is
possible, but not if Truecrypt is in control of where all the data are
going?

Something has to be unencrypted somewhere, otherwise the disk will be
unusable. Some programs might overcome this by taking care of that
business themselves, but surely that is just moving the same risk elsewhere?

Andy

Sebastian G.
02-07-08, 04:41 PM
Cyberiade.it Anonymous Remailer wrote:

> Sebastian G. wrote:
>
>> 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.
>
> It "can", but that's a destructive process and there's absolutely no
> way to bootstrap any operating system that you might install after the
> fact.
>
> You guys aren't thinking this through.


Maybe you're just stupid. Why do you narrow your views to one drive? You can
have two or more. One contains the operating system, does the pre-boot stuff
and has an identifyable partition table. The second drive is meant to store
data, and is fully encrypted, including the partition table.

Ari
02-08-08, 01:02 AM
On 7 Feb 2008 16:00:31 +0100, Cyberiade.it Anonymous Remailer wrote:

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

Hell, let's hope this is one step back which proceeds several forward. I
admire those guys, I hope they haven't fallen over a cliff.
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

George Orwell
02-08-08, 01:04 AM
nemo_outis wrote:

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

Talk about thick... you don't even have the slightest clue what whole
disk encryption really is. Got some more bad news for you sonny.
Bestcrypt ain't on that list. That's right, it's not whole disk either.

*snicker*

You've been making a supreme fool of yourself all this time, puffing
your chest and calling other people stupid in your usual self
aggrandizing way, so just to rub your nose in it here's the current
contenders as of 11/09/2007.

http://www.full-disc-encryption.com/Full_Disc_Encryption.html

Read'm and weep, bitch. Maybe some day you'll learn to not be
such an arrogant jackass. :)


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
02-08-08, 01:28 AM
George Orwell <nobody@mixmaster.it> wrote in
news:a6b52b3f53d8d9e5e5666d21fd185ed6@mixmaster.it:

> Talk about thick... you don't even have the slightest clue what whole
> disk encryption really is. Got some more bad news for you sonny.
> Bestcrypt ain't on that list. That's right, it's not whole disk
> either.

Another bit of stupidity from you, you mouthbreathing twit.

Bestcrypt Volume Encryption for Windows is among the most advanced full-HD
OTFE encryption systems. Not only can it encrypt all HD partitions on all
HDs (including the boot/system one) it supports complete encyption of
spanned, mirrored, and striped volumes, as well as RAID 5 volumes. It also
supports physical tokens in addition to a password/passphrase for
additional security.

http://www.jetico.com/bcve.htm

Now do be a good little moron and **** off.

Regards,

nemo_outis
02-08-08, 01:31 AM
George Orwell <nobody@mixmaster.it> wrote in
news:a6b52b3f53d8d9e5e5666d21fd185ed6@mixmaster.it:

> Talk about thick... you don't even have the slightest clue what whole
> disk encryption really is. Got some more bad news for you sonny.
> Bestcrypt ain't on that list. That's right, it's not whole disk
> either.

Another bit of stupidity from you, you mouthbreathing twit.

Bestcrypt Volume Encryption for Windows is among the most advanced full-HD
OTFE encryption systems. Not only can it encrypt all HD partitions on all
HDs (including the boot/system one) it supports complete encryption of
spanned, mirrored, and striped volumes, as well as RAID 5 volumes. It also
supports physical tokens in addition to a password/passphrase for
additional security.

http://www.jetico.com/bcve.htm

Now do be a good little moron and **** off.

Regards,

Anonymous
02-08-08, 01:49 AM
Sebastian G. wrote:

> Cyberiade.it Anonymous Remailer wrote:
>
> > Sebastian G. wrote:
> >
> >> 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.
> >
> > It "can", but that's a destructive process and there's
> > absolutely no way to bootstrap any operating system that you
> > might install after the fact.
> >
> > You guys aren't thinking this through.
>
>
> Maybe you're just stupid. Why do you narrow your views to one
> drive? You can have two or more. One contains the operating
> system, does the pre-boot stuff and has an identifyable partition
> table. The second drive is meant to store data, and is fully
> encrypted, including the partition table.

Maybe you're just a lying sack, desperately trying to change the
rules to try and win a point.

Can you install an OS to ANY device that's been encrypted by
Truecrypt? No.

Case closed. Have a nice day.

Next!

Cyberiade.it Anonymous Remailer
02-08-08, 02:11 AM
nemo_outis wrote:

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

Problem is, with Truecrypt you don't have that choice.

Go ahead and try it. Encrypt an entire drive and see if you can
install an OS to it.

Whole disk my ass. LOL!

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

Merk
02-08-08, 02:51 AM
After all this constructive and philosophical debate, I have decided to
download Truecrypt5 myself and test it on my system. I will try an
encrypt the whole OS see what happen, of course everything is backed up.

Ari
02-08-08, 03:48 AM
On Fri, 8 Feb 2008 08:04:27 +0100 (CET),

> nemo_outis wrote:
> <****>


> George Orwell wrote:

> <Crap>

STOP!/STOP!/ *STOP*

Natalie, the popcorn, and hurry up, the games have begun!!

Sebastian G.
02-08-08, 04:47 AM
Anonymous wrote:


>> Maybe you're just stupid. Why do you narrow your views to one
>> drive? You can have two or more. One contains the operating
>> system, does the pre-boot stuff and has an identifyable partition
>> table. The second drive is meant to store data, and is fully
>> encrypted, including the partition table.
>
> Maybe you're just a lying sack, desperately trying to change the
> rules to try and win a point.
>
> Can you install an OS to ANY device that's been encrypted by
> Truecrypt? No.


That has never been a requirement.

Sebastian G.
02-08-08, 04:56 AM
Cyberiade.it Anonymous Remailer wrote:


>> 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.
>
> Problem is, with Truecrypt you don't have that choice.


So then my fully encrypted harddisk with even an encrypted partition table
is pure imagination?

> Go ahead and try it. Encrypt an entire drive and see if you can
> install an OS to it.


Who cares for installing an OS? This drive only contains data, the OS is on
another media.

Casper
02-08-08, 05:14 AM
>
> Who cares for installing an OS? This drive only contains data, the OS is on
> another media.

LOL LOL LOL >:|

You will never understand what we are talking about.
Maybe your posts should not appear in alt.privacy at all
I am putting up a filter.

And who the f*** wants a clear OS to hide all the communist
propaganda we have been downloading from the internet?

The day the CIA kicks your door in you are done for, have a
nice trip to Guantanamo! lol

Phil Carmody
02-08-08, 05:18 AM
Casper <spam@spam.spam> writes:
> >
> > Who cares for installing an OS? This drive only contains data, the
> > OS is on another media.
>
> LOL LOL LOL >:|
>
> You will never understand what we are talking about.
> Maybe your posts should not appear in alt.privacy at all
> I am putting up a filter.

Anything which separates alt.privacy from sci.crypt is
a good thing. Keeping your ill-thought-out gibberings
off sci.crypt would in particular be appreciated.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

Sebastian G.
02-08-08, 08:00 AM
Casper wrote:

>> Who cares for installing an OS? This drive only contains data, the OS is on
>> another media.
>
> LOL LOL LOL >:|
>
> You will never understand what we are talking about.


We were talking about full disc encryption. This is totally unrelated to
pre-boot authentication, in fact it is mutually exclusive.

> And who the f*** wants a clear OS to hide all the communist
> propaganda we have been downloading from the internet?


The OS can be easily encrypted with a partition-wise encryption with
pre-boot authentication.


But well, why should I discuss with someone who is even too stupid to create
a technically valid posting?

nemo_outis
02-08-08, 09:07 AM
"Sebastian G." <seppi@seppig.de> wrote in
news:612qppF1tk96tU4@mid.dfncis.de:

> Cyberiade.it Anonymous Remailer wrote:
>
>
>>> 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.
>>
>> Problem is, with Truecrypt you don't have that choice.
>
>
> So then my fully encrypted harddisk with even an encrypted partition
> table is pure imagination?
>
>> Go ahead and try it. Encrypt an entire drive and see if you can
>> install an OS to it.
>
>
> Who cares for installing an OS? This drive only contains data, the OS
> is on another media.


Yep, Sebastian, you've got it entirely right.

Yes, Truecrypt in addition to file-based and partition-based encrypted
storage, also supports device-based OTFE storage. The device-based
versions do not have a partition table and are essentially
"floppy/superfloppy-ish." Device-based encrypted storage is primarily
useful for floppy disks, USB pendrives, and such but the Truecrypt docs
say a HD can also be be used this way.

Superfloppyish-based encrypted storage is only suitable for data storage,
not for a bootable Windows system. In fact, independent of any
encryption aspects, Windows has been deliberately crippled so it can NOT
boot/run from removable media such as superfloppies (Microsoft says it's
a licencing issue). (Some folks have crafted end-runs around this
limitation of Windows, using tricks such as RAM drives.)

But all this is beside the point. With Truecrypt 5 one can now encrypt
*any and all partitions* on any drive, including the boot/system
partition. This is all that is needed for complete OTFE protected
storage for both the Windows system itself and all data on it.

Regards,

nemo_outis
02-08-08, 09:10 AM
Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote in
news:87hcgjd7c2.fsf@nonospaz.fatphil.org:

> Anything which separates alt.privacy from sci.crypt is
> a good thing. Keeping your ill-thought-out gibberings
> off sci.crypt would in particular be appreciated.
>
> Phil

Let me suggest that you start a moderated group to protect your delicate
sensibilites. Or, as an alternative, that you go **** yourself.

Regards,

Sebastian G.
02-08-08, 09:25 AM
nemo_outis wrote:


> Superfloppyish-based encrypted storage is only suitable for data storage,
> not for a bootable Windows system. In fact, independent of any
> encryption aspects, Windows has been deliberately crippled so it can NOT
> boot/run from removable media such as superfloppies (Microsoft says it's
> a licencing issue).


Nonsense. Microsoft has only disabled this option by default, since they
don't want to support such configurations.

> (Some folks have crafted end-runs around this
> limitation of Windows, using tricks such as RAM drives.)


.... or by simple setting the required options.

> But all this is beside the point. With Truecrypt 5 one can now encrypt
> *any and all partitions* on any drive, including the boot/system
> partition. This is all that is needed for complete OTFE protected
> storage for both the Windows system itself and all data on it.


There are still some limitations. For example, in a dual boot configuration
the system partition must be identical to the boot partition and only the
original MBR works. For non-dual boot, you can have one and only one of
these options.

nemo_outis
02-08-08, 09:58 AM
"Sebastian G." <seppi@seppig.de> wrote in
news:613aivF1ti8nnU1@mid.dfncis.de:

> nemo_outis wrote:
>> Superfloppyish-based encrypted storage is only suitable for data
>> storage, not for a bootable Windows system. In fact, independent of
>> any encryption aspects, Windows has been deliberately crippled so it
>> can NOT boot/run from removable media such as superfloppies
>> (Microsoft says it's a licencing issue).

> Nonsense. Microsoft has only disabled this option by default, since
> they don't want to support such configurations.

Ahh, that's more like it. I feel much better when Sebastian reverts to
his old self and spouts ********. The world is running as expected.

No, Sebastian, it''s not nonsense. Windows XP has no such "option." To
boot XP from removable media you must resort to hacks such as using bits
& pieces from the embedded version - which is clearly a licence
violation.

>> But all this is beside the point. With Truecrypt 5 one can now
>> encrypt *any and all partitions* on any drive, including the
>> boot/system partition. This is all that is needed for complete OTFE
>> protected storage for both the Windows system itself and all data on
>> it.

> There are still some limitations. For example, in a dual boot
> configuration the system partition must be identical to the boot
> partition and only the original MBR works. For non-dual boot, you can
> have one and only one of these options.

There is no doubt that Truecrypt can go on adding additional features,
bells, and whistles for a very long time. However, Truecrypt v5, as it
now stands, provides ALL the core functionality necessary for complete
OTFE protection of both the Windows OS and all data on all drives.

Regards,

Nomen Nescio
02-08-08, 10:10 AM
nospamatall wrote:

> Casper wrote:
> >> 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.
> >
> >
> The difference is that the partition info and some other stuff may not
> be encrypted. This doesn't answer my question though. Do any data leak
> into the non-user partitions? I had heard that some shyster companies
> use these partitions for their nefarious 'DRM' so I spose it is
> possible, but not if Truecrypt is in control of where all the data are
> going?

I don't think it's ever going to be 100% possible to guarantee that any
software running atop and operating system can successfully keep that
host from storing information about what that program does, somewhere
the program isn't aware of. It is, after all, the operating system
that's running the show.

Protected memory schemes and such go a good distance towards limiting
this sort of information "sharing", but they're as far from perfect as
can be and still be workable. Virtualization and other "sandbox" schemes
of that type are a lot better. Dual booting can be trivially configured
to minimalize that sharing, and "live" environments like CD's generally
come configured that way by default. Then at the end of the spectrum you
have physical swapping of storage devices which makes it an
impossibility.

The interesting thing about Truecrypt's hidden volume feature is that
one may be able to simulate physical swapping of devices in software.
I'd consider strong encryption every bit as secure as disconnecting a
drive for any practical purpose. ;)

Sebastian G.
02-08-08, 10:18 AM
nemo_outis wrote:


> No, Sebastian, it''s not nonsense. Windows XP has no such "option." To
> boot XP from removable media you must resort to hacks such as using bits
> & pieces from the embedded version - which is clearly a licence
> violation.


Nonsense. You can either use the preinstall kit or manually configure an
unattended installation. Making Windows boot from USB requires nothing but
moving the USB bus driver entry from the list of general I/O extenders to
the boot bus extender list, and changing the startup type of the usb mass
storage driver to make it load at boot time. This can be done for FireWire,
SD Card and iSCSI targets as well, and requires exactly no data from Windows CE.

> There is no doubt that Truecrypt can go on adding additional features,
> bells, and whistles for a very long time. However, Truecrypt v5, as it
> now stands, provides ALL the core functionality necessary for complete
> OTFE protection of both the Windows OS and all data on all drives.

However, not on all setups. And "protection" is a quite funny term,
considering that just some hours ago I had reported my full analysis on a
privilege escalation vulnerability that has been carried over from version
4.3a without any changes.

George Orwell
02-08-08, 10:23 AM
nemo_outis wrote:

Did you think nobody would check this "cite", ya' pathetic lying worm?

> Bestcrypt Volume Encryption for Windows is among the most advanced full-HD
> OTFE encryption systems. Not only can it encrypt all HD partitions on all
> HDs (including the boot/system one) it supports complete encyption of
> spanned, mirrored, and striped volumes, as well as RAID 5 volumes. It also
> supports physical tokens in addition to a password/passphrase for
> additional security.
>
> http://www.jetico.com/bcve.htm

That paragraph doesn't exist at all on that page. Or anywhere else on
Jetico's site that I can find. You even misspelled "encryption" in one
of the two posts where you tried to pass off your obvious lie as a
cite. No kidding *******, check line 3 in each.

What a bumbling buffoon!

*snicker*

Here's what's actually on Jetico's own pages, just to rub your nose in
it a little longer...

"The chapter explains why BestCrypt Volume Encryption (a line in
BestCrypt family of encryption software products) has got Volume
Encryption name. Many people may think that Volume Encryption is the
same as Partition Encryption or even Whole Disk Encryption. Sometimes
it is really so, but not always, and it is worth to learn about the
difference."

http://www.jetico.com/bcve_web_help/index.php?info=html/01_introduction/02_what_is_ve.htm

*snicker*

>
> Now do be a good little moron and **** off.

Begging won't work, bitch. I've got you under my heel again, and to
tell the truth I'm just enjoying the crunching sound way too much.

Have a nice day. :-p

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

Anonymous
02-08-08, 10:53 AM
Cyberiade.it Anonymous Remailer wrote:

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

ROTFL!

I did the EXACT same thing. ;-)

>

Cyberiade.it Anonymous Remailer
02-08-08, 11:00 AM
Sebastian G. wrote:

> Casper wrote:
>
> >> Who cares for installing an OS? This drive only contains data, the OS is on
> >> another media.
> >
> > LOL LOL LOL >:|
> >
> > You will never understand what we are talking about.
>
>
> We were talking about full disc encryption. This is totally unrelated to
> pre-boot authentication, in fact it is mutually exclusive.

On the contrary. FDE can't possibly exist without some sort of pre-boot
authentication. The very definition of "full disk" precludes any access
at all without it.

>
> > And who the f*** wants a clear OS to hide all the communist
> > propaganda we have been downloading from the internet?
>
>
> The OS can be easily encrypted with a partition-wise encryption with
> pre-boot authentication.

Yes, and that's what Truecrypt is.

> But well, why should I discuss with someone who is even too stupid to create
> a technically valid posting?

Says you, whose entire arsenal consists of calling everyone else stupid
and spewing made up nonsense.

nemo_outis
02-08-08, 11:04 AM
"Sebastian G." <seppi@seppig.de> wrote in
news:613dm4F1ff4uuU1@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> No, Sebastian, it''s not nonsense. Windows XP has no such "option."
>> To boot XP from removable media you must resort to hacks such as
>> using bits & pieces from the embedded version - which is clearly a
>> licence violation.
>
>
> Nonsense. You can either use the preinstall kit or manually configure
> an unattended installation. Making Windows boot from USB requires
> nothing but moving the USB bus driver entry from the list of general
> I/O extenders to the boot bus extender list, and changing the startup
> type of the usb mass storage driver to make it load at boot time. This
> can be done for FireWire, SD Card and iSCSI targets as well, and
> requires exactly no data from Windows CE.

Yes, Sebastian, exactly as I said: you can only do it if you hack
Windows.

You have already repeatedly demonstrated that you can make errors faster
than I can correct them. Accordingly, I'm not going to further pursue
this latest error of yours since it has nothing to do with the matter at
hand: Truecrypt and full-HD OTFE encryption.


>> There is no doubt that Truecrypt can go on adding additional
>> features, bells, and whistles for a very long time. However,
>> Truecrypt v5, as it now stands, provides ALL the core functionality
>> necessary for complete OTFE protection of both the Windows OS and all
>> data on all drives.

> However, not on all setups. And "protection" is a quite funny term,
> considering that just some hours ago I had reported my full analysis
> on a privilege escalation vulnerability that has been carried over
> from version 4.3a without any changes.

Like all software, Truecrypt may contain bugs. The alleged bug you
mention does not affect its OTFE protection of the OS and data which only
truly comes into not play when the machine is off. Nor does Truecrypt
support every non-standard variant configuration, such as dual-booting.

However, what I said above is irrefragably true: Truecrypt v5, as it now
stands, provides ALL the core functionality necessary for complete OTFE
protection of both the Windows OS and all data on all drives.

Regards,

Anonymous
02-08-08, 11:09 AM
Sebastian G. wrote:

> nemo_outis wrote:
>
>
> > Superfloppyish-based encrypted storage is only suitable for data
> > storage, not for a bootable Windows system. In fact, independent
> > of any encryption aspects, Windows has been deliberately crippled
> > so it can NOT boot/run from removable media such as superfloppies
> > (Microsoft says it's a licencing issue).
>
>
> Nonsense. Microsoft has only disabled this option by default, since
> they don't want to support such configurations.

Maybe you can explain teh difference between "crippled" and "disabled"?

Argue for the sake of argument much? <sheesh!>

Sebastian G.
02-08-08, 11:23 AM
nemo_outis wrote:


> Yes, Sebastian, exactly as I said: you can only do it if you hack
> Windows.


Just ignoring the fact that this is all documented, and even implemented
with Microsoft's very own preinstall kit.

> However, what I said above is irrefragably true: Truecrypt v5, as it now
> stands, provides ALL the core functionality necessary for complete OTFE
> protection of both the Windows OS and all data on all drives.

Doesn't make it any more true: When using pre-boot authentication, the
partition table is unencrypted.

Sebastian G.
02-08-08, 11:23 AM
Anonymous wrote:


>> Nonsense. Microsoft has only disabled this option by default, since
>> they don't want to support such configurations.
>
> Maybe you can explain teh difference between "crippled" and "disabled"?


Documentation and partial support.

nemo_outis
02-08-08, 11:29 AM
George Orwell <nobody@mixmaster.it> wrote in
news:6cb67025e78b69b29b7578cf72c420f4@mixmaster.it:

> nemo_outis wrote:
>
> Did you think nobody would check this "cite", ya' pathetic lying worm?
>
>> Bestcrypt Volume Encryption for Windows is among the most advanced
>> full-HD OTFE encryption systems. Not only can it encrypt all HD
>> partitions on all HDs (including the boot/system one) it supports
>> complete encyption of spanned, mirrored, and striped volumes, as well
>> as RAID 5 volumes. It also supports physical tokens in addition to a
>> password/passphrase for additional security.
>>
>> http://www.jetico.com/bcve.htm
>
> That paragraph doesn't exist at all on that page. Or anywhere else on
> Jetico's site that I can find.


Of course, you ****ing moron, that paragraph is mine, in my words - there
are no quotation marks, no "Jeticos says" in it. It's a simple
description and characterization of the program clearly provided by me,
the author of the post, the fellow with his name in the "From" header -
just as anyone who wasn't a moron like you would expect. You've just
failed to comprehend plain English - yet again.

The cite was provided for convenience to allow readers to check for
themselves what Bestcrypt says about its product. And the cite was set
off in a completely separate paragraph specifically so as not to directly
link it to my words above.

As for what Bestcrypt says about the term "volume," you would understand,
if you weren't such a colossal moron, that Bestcrypt uses the term in a
broader sense than Truecrypt to refer to "high-level storage entities"
that can, inter alia, extend across multiple hard drives (such as spanned
volumes or RAID 5). Jetico makes the distinction between "volume" and
"whole-disk" encryption because its product can support seamless
"volumes" which may be stored across several physical HDs.

Now do be a good moron and **** off.

Regards,

nemo_outis
02-08-08, 11:36 AM
"Sebastian G." <seppi@seppig.de> wrote in
news:613hfiF1tqd2kU2@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> Yes, Sebastian, exactly as I said: you can only do it if you hack
>> Windows.

> Just ignoring the fact that this is all documented, and even
> implemented with Microsoft's very own preinstall kit.

No, Sebastian, you're dead wrong. But as I said in the previous post, I
don't have time to follow you into every thicket of misunderstanding you
fall into to disentangle you.

>> However, what I said above is irrefragably true: Truecrypt v5, as it
>> now stands, provides ALL the core functionality necessary for
>> complete OTFE protection of both the Windows OS and all data on all
>> drives.
>
> Doesn't make it any more true: When using pre-boot authentication, the
> partition table is unencrypted.

And it doesn't matter a whit! Truecrypt can completely protect the OS and
all data.

Regards,

George Orwell
02-08-08, 11:38 AM
nemo_outis wrote:

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

"We call encryption software working with volumes Volume Encryption
software. Note that if Volume Encryption software encrypts a volume
consisting of a single partition, for the user it will give the same
result as Partition Encryption software. If a single partition occupies
the whole hard drive, Volume Encryption will be equal both to Whole
Disk Encryption and Partition Encryption. Encrypting of basic partition
C: on Figure 3 below illustrates that."

http://www.jetico.com/bcve_web_help/index.php?info=html/01_introduction/02_what_is_ve.htm

*snicker*

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

I see. So now you believe you're smarter than all the encryption
and cryptanalysis experts that ever lived, combined.

You've already had your ears boxed with one cite you couldn't even find
the courage to reply to. Care to try for some more?

> As for Truecrypt supposedly not being a whole-disk encryption program,
> that's just plain wrong.

"Volume Encryption software works with volume as with a single portion
of data. Volume is always in one of the two definite states: if
password is not entered, the whole volume is not accessible. If the
user enters the proper password and opens the volume, all its parts,
even stored on different hard drives, become accessible. In our
opinion, working with volumes is more native both for the user and
computer, because it is a volume that stores a complete filesystem
structure and a complete tree of the user's files. As in the modern
world single volume stores data scattered on a number of physical
disks, it is more convenient and safe to manage a volume, rather than
work with every physical drive separately."

http://www.jetico.com/bcve_web_help/index.php?info=html/01_introduction/02_what_is_ve.htm

*snicker*

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
02-08-08, 11:40 AM
is Nomen Nescio <nobody@dizum.com> wrote in
news:1d77e939150828e3747369f16981a543@dizum.com:

....
> I don't think it's ever going to be 100% possible to guarantee that
> any software running atop and operating system can successfully keep
> that host from storing information about what that program does,
> somewhere the program isn't aware of. It is, after all, the operating
> system that's running the show.

Absolutely correct. In fact, I posted several years ago how, in principle,
how a rogue OS could leak the key of an OTFE program into the very HD
storage it is protecting - and do it while not corrupting that OTFE program
in any way but using it completely according to Hoyle.

I'll be happy to post the method again if anyone cares.

Regards,

nemo_outis
02-08-08, 11:45 AM
George Orwell <nobody@mixmaster.it> wrote in
news:bf6ea79edec361e1aad589185e7d1167@mixmaster.it:

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

> I see. So now you believe you're smarter than all the encryption
> and cryptanalysis experts that ever lived, combined.


You see little and comprehend less.

If you have some argument to show how an unencrypted partition table would
permit decrypting the contents of of an encrypted partition, then make it.
If not, then, as I have repeatedly suggested: Do be a good little moron and
**** off.

Regards,

Anonymous
02-08-08, 12:40 PM
Sebastian G. wrote:

> Anonymous wrote:
>
>
> >> Nonsense. Microsoft has only disabled this option by default, since
> >> they don't want to support such configurations.
> >
> > Maybe you can explain teh difference between "crippled" and "disabled"?
>
>
> Documentation and partial support.

Telling someone their leg is irreparably broken and handing the a set
of crutches doesn't make them any less crippled or disabled.

You're engaging in a semantics quibble that doesn't even exist, but
then you seem to enjoy that sort of thing. Never have to admit you were
wrong about something if you just make up the rules as you go, now do
you? :(

Anonymous
02-08-08, 12:56 PM
nospamatall wrote:

> Anonymous wrote:
> > 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 would have thought that this is not an issue with TrueCrypt,
> because the hidden partition is within the free space of another
> encrypted partition and thus doesn't show up anywhere else?

except maybe in caches, swap space, histories and logs, last
modified fields, etc...........

with whole disk nothing can ever be leaked to another partition or
anywhere else that anyone can see without owning the keys.
partition encryption can leak like a sieve.

George Orwell
02-08-08, 01:09 PM
nemo_outis wrote:

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

Nope! I fact with *true* whole disk encryption there is absolutely no
unencrypted information on a device at all.

Puzzle over it a while and then I'll do the nose rubbing thing some
more. :)

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

Sebastian G.
02-08-08, 01:17 PM
nemo_outis wrote:


> And it doesn't matter a whit! Truecrypt can completely protect the OS and
> all data.


And this was never disputed. Disputed was the claim that the entire disk was
encrypted whereas the partition table and the boot sector is obviously not.
And sadly since TrueCrypt does not offer any mechanism so store the boot
sector on another media, both are mutually exclusive.

And it does matter, since it disallows for plausible deniability.

Sebastian G.
02-08-08, 01:18 PM
nemo_outis wrote:


> If you have some argument to show how an unencrypted partition table would
> permit decrypting the contents of of an encrypted partition, then make it.


It doesn't. What it permits is to differ the encrypted disc from random
data, and it permits knowledge about the partitioning of the volume inside
the encrypted container.

Sebastian G.
02-08-08, 01:21 PM
Cyberiade.it Anonymous Remailer wrote:


> On the contrary. FDE can't possibly exist without some sort of pre-boot
> authentication.


It can, if you stop insisting that the encrypted disc must contain the
operating system.

> The very definition of "full disk" precludes any access at all without it.


Obviously wrong.

>> But well, why should I discuss with someone who is even too stupid to create
>> a technically valid posting?
>
> Says you, whose entire arsenal consists of calling everyone else stupid
> and spewing made up nonsense.

No, that would be you.

Sebastian G.
02-08-08, 01:23 PM
Anonymous wrote:

> Sebastian G. wrote:
>
>> Anonymous wrote:
>>
>>
>>>> Nonsense. Microsoft has only disabled this option by default, since
>>>> they don't want to support such configurations.
>>> Maybe you can explain teh difference between "crippled" and "disabled"?
>>
>> Documentation and partial support.
>
> Telling someone their leg is irreparably broken and handing the a set
> of crutches doesn't make them any less crippled or disabled.


Making bad analogies doesn't make your point any less moot.

> You're engaging in a semantics quibble that doesn't even exist, but
> then you seem to enjoy that sort of thing. Never have to admit you were
> wrong about something if you just make up the rules as you go, now do
> you? :(


Well, then tell me just one thing: If it was really crippled, then why was I
able to unleash this functionality with nothing but a text editor and an
archiver (for unpacking and optionally repacking the CABinet archives)?

Sebastian G.
02-08-08, 01:27 PM
Anonymous wrote:


> except maybe in caches, swap space, histories and logs, last
> modified fields, etc...........
>
> with whole disk nothing can ever be leaked to another partition or
> anywhere else that anyone can see without owning the keys.
> partition encryption can leak like a sieve.


Which is wrong again. For all those FDE products which use CBC mode, the
swap file is likely to contain an IV, which leaks the first block of data
for every CBC block. For LRW, swapping out an empty page with the LRW tweak
key at the beginning or the end will allow an attacker to retrieve the LRW
tweak, and therefore distinguishing the encrypted volume from random data.
For ESSIV it's the same.

Lucky you that TrueCrypt 5.0 introduced XTS as the only mode for creating
new encrypted volumes.

Nomen Nescio
02-08-08, 02:30 PM
nemo_outis wrote:

> George Orwell <nobody@mixmaster.it> wrote in
> news:6cb67025e78b69b29b7578cf72c420f4@mixmaster.it:
>
> > nemo_outis wrote:
> >
> > Did you think nobody would check this "cite", ya' pathetic
> > lying worm?
> >
> >> Bestcrypt Volume Encryption for Windows is among the most
> >> advanced full-HD OTFE encryption systems. Not only can it
> >> encrypt all HD partitions on all HDs (including the
> >> boot/system one) it supports complete encyption of spanned,
> >> mirrored, and striped volumes, as well as RAID 5 volumes. It
> >> also supports physical tokens in addition to a
> >> password/passphrase for additional security.
> >> http://www.jetico.com/bcve.htm
> >
> > That paragraph doesn't exist at all on that page. Or anywhere
> > else on Jetico's site that I can find.
>
>
> Of course, you ****ing moron, that paragraph is mine, in my words
> - there are no quotation marks, no "Jeticos says" in it. It's a

ROTFL!

What is was, *******, was you getting caught playing your little
kid games and showing everyone just what a ****ing liar you can be
when you're wrong.

What is was, *******, was you making up a cite then giving a link
that said exactly the opposite.

> As for what Bestcrypt says about the term "volume," you would
> understand, if you weren't such a colossal moron, that Bestcrypt

God you're a ****ing jerk. Bestcrypt ****ing well states in no
uncertain terms that volume and whole disk are different things,
that their product is volume encryption, and that nemo_retardus is
wrong. But never one to let something like obvious facts get in
your way, here you are telling someone ELSE they don't understand
something.

You really managed to display your spots today liar, and they're
looking like you **** all over yourself.

> uses the term in a broader sense than Truecrypt to refer to
> "high-level storage entities" that can, inter alia, extend across
> multiple hard drives (such as spanned volumes or RAID 5). Jetico
> makes the distinction between "volume" and "whole-disk"
> encryption because its product can support seamless "volumes"
> which may be stored across several physical HDs.
>
> Now do be a good moron and **** off.
>
> Regards,
>

nospamatall
02-08-08, 03:06 PM
Sebastian G. wrote:
> Anonymous wrote:
>
>
>>> Maybe you're just stupid. Why do you narrow your views to one
>>> drive? You can have two or more. One contains the operating
>>> system, does the pre-boot stuff and has an identifyable partition
>>> table. The second drive is meant to store data, and is fully
>>> encrypted, including the partition table.
>>
>> Maybe you're just a lying sack, desperately trying to change the
>> rules to try and win a point.
>>
>> Can you install an OS to ANY device that's been encrypted by
>> Truecrypt? No.
>
>
> That has never been a requirement.

You can install an OS and then encrypt the whole drive. Maybe you can do
the other thing too, but I doubt we would find out anything useful from
these folks!

nospamatall
02-08-08, 03:07 PM
Casper wrote:
>>
>> Who cares for installing an OS? This drive only contains data, the OS
>> is on another media.
>
> LOL LOL LOL >:|
>
> You will never understand what we are talking about.
> Maybe your posts should not appear in alt.privacy at all
> I am putting up a filter.
Maybe if you elucidated what the **** you're talking about instead of
being a smug bastard with no info to offer...

nospamatall
02-08-08, 03:09 PM
Phil Carmody wrote:
> Casper <spam@spam.spam> writes:
>>> Who cares for installing an OS? This drive only contains data, the
>>> OS is on another media.
>> LOL LOL LOL >:|
>>
>> You will never understand what we are talking about.
>> Maybe your posts should not appear in alt.privacy at all
>> I am putting up a filter.
>
> Anything which separates alt.privacy from sci.crypt is
> a good thing. Keeping your ill-thought-out gibberings
> off sci.crypt would in particular be appreciated.
>
> Phil
You're welcome to kill the thread and then anyone who wants to read it
still can. You think usenet is just for you?

nospamatall
02-08-08, 03:11 PM
nemo_outis wrote:
> "Sebastian G." <seppi@seppig.de> wrote in
> news:612qppF1tk96tU4@mid.dfncis.de:
>
>> Cyberiade.it Anonymous Remailer wrote:
>>
>>
>>>> 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.
>>> Problem is, with Truecrypt you don't have that choice.
>>
>> So then my fully encrypted harddisk with even an encrypted partition
>> table is pure imagination?
>>
>>> Go ahead and try it. Encrypt an entire drive and see if you can
>>> install an OS to it.
>>
>> Who cares for installing an OS? This drive only contains data, the OS
>> is on another media.
>
>
> Yep, Sebastian, you've got it entirely right.
>
> Yes, Truecrypt in addition to file-based and partition-based encrypted
> storage, also supports device-based OTFE storage. The device-based
> versions do not have a partition table and are essentially
> "floppy/superfloppy-ish." Device-based encrypted storage is primarily
> useful for floppy disks, USB pendrives, and such but the Truecrypt docs
> say a HD can also be be used this way.
>
> Superfloppyish-based encrypted storage is only suitable for data storage,
> not for a bootable Windows system. In fact, independent of any
> encryption aspects, Windows has been deliberately crippled so it can NOT
> boot/run from removable media such as superfloppies (Microsoft says it's
> a licencing issue). (Some folks have crafted end-runs around this
> limitation of Windows, using tricks such as RAM drives.)
>
> But all this is beside the point. With Truecrypt 5 one can now encrypt
> *any and all partitions* on any drive, including the boot/system
> partition. This is all that is needed for complete OTFE protected
> storage for both the Windows system itself and all data on it.
>
> Regards,

Thank you. Why is cryptography inhabited by such obnoxious anti-social
twats?

Nomen Nescio
02-08-08, 04:30 PM
In article <613oc6F1taan2U4@mid.dfncis.de>
"Sebastian G." <seppi@seppig.de> wrote:
>
> Cyberiade.it Anonymous Remailer wrote:
>
<snip>
>
> > The very definition of "full disk" precludes any access at all without it.
>
>
> Obviously wrong.
>
<snip>

Can you explain what happens when the OS is encrypted and
the computer is turned on? How can booting the OS
take place if the OS is encrypted?

Isn't the function of "pre-boot authentication" in this
instance to allow decryption and proceed with booting
the OS?

IOW, if you didn't have the pre-boot authentication, the
computer would blank screen and not go any further.

Are you making a distinction that is misleading? Like
"Full disk doesn't necessarily include the OS." But
the previous poster(s) are all talking about encrypting
the C: drive WITH the OS (whether other drives are encrypted
or not).

nemo_outis
02-08-08, 04:52 PM
George Orwell <nobody@mixmaster.it> wrote in
news:cfba7ec8f8b207e0a1bd089fe3255024@mixmaster.it:

> nemo_outis wrote:
>
>> There must - necessarily! - be a small amount of unencrypted code on
>> the boot/system volume. This is invariably located on track 0.
>
> Nope! I fact with *true* whole disk encryption there is absolutely no
> unencrypted information on a device at all.

Uhh, doofus, Windows cannot boot from a completely encrypted disk because
there's nothing to decrypt those first bytes to even get the process
started. Oddly enough, encrypted code is not executable. So if a system
does not have a storage medium (i.e., boot drive) with some unencrypted
boot loader on it, the system can't boot to HD. QED

Those unencrypted bytes must be stored somewhere, and the BIOS looks at
each storage device (MPTs and GPTs for HDs) to see which one is active to
pass continuation of booting off to it. No unencrypted boot code stub,
no boot from HD.

Of course, if all you want to do is store data then Truecrypt can encrypt
an entire drive in "superfloppy-ish" mode. But such a drive cannot boot
Windows - this is a limitation of Windows, not full HD OTFE systems.

As for an the unencrypted boot stub making it plain yyou are using
encryption - yep, it does.

And I hgave the workaround for that problem several posts back:
overwrite track zeo with random junk after a session and restore the
track 0 (most convenioently using the OTFE recovery disk) before each new
session. This results in a drive being completely filled with ostensibly
random data between uses.

Regards,

nemo_outis
02-08-08, 05:02 PM
"Sebastian G." <seppi@seppig.de> wrote in
news:613o4rF1taan2U2@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> And it doesn't matter a whit! Truecrypt can completely protect the OS
>> and all data.
>
>
> And this was never disputed. Disputed was the claim that the entire
> disk was encrypted whereas the partition table and the boot sector is
> obviously not. And sadly since TrueCrypt does not offer any mechanism
> so store the boot sector on another media, both are mutually
> exclusive.
>
> And it does matter, since it disallows for plausible deniability.

If that "other media" is permanently attached to the system (i.e.,
"fixed") then plausible deniability is still shot. Since Microsoft only
supports booting normal Windows (not PE, not embedded) from fixed media,
what you want is unachievable with Windows as the OS (without violating
the licence).

However, if you are still worried about plausible deniability (although
there being a good reason for having a system that contains only disks
with random data strikes me as the epitome of implausible) then do as I
suggested several posts earlier in this thread: overwrite track 0 with
random junk after each session and restore it again at the start of the
next session (most conveniently, by using the OTFE recovery disk/CD).

Now be sure to post again, Sebastian, with more of your nonsensical
attempts to complicate and obfuscate the straighfoprward.

Regards,

nemo_outis
02-08-08, 05:04 PM
"Sebastian G." <seppi@seppig.de> wrote in
news:613o84F1taan2U3@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> If you have some argument to show how an unencrypted partition table
>> would permit decrypting the contents of of an encrypted partition,
>> then make it.
>
>
> It doesn't. What it permits is to differ the encrypted disc from
> random data, and it permits knowledge about the partitioning of the
> volume inside the encrypted container.

But it is a limitation of Windows, not of Truecrypt or any other whole-disk
OTFE program, that causes the difficulty. Go give old Bill Gates a call
and leave the rest of us in peace to contentedly use the magnificent new
Truecrypt 5.

Regards,

nemo_outis
02-08-08, 05:07 PM
Nomen Nescio <nobody@dizum.com> wrote in
news:b37ff94e4b489cb0606a73458d64d04b@dizum.com:

>> Of course, you ****ing moron, that paragraph is mine, in my words
>> - there are no quotation marks, no "Jeticos says" in it. It's a

I would suggest that you enroll in a reading comprehension course.
However, your problem is far more deep-seated than that: not an inability
to read for understanding, but the mental incapability to understand at
all.

Now **** off, 'tard.

nemo_outis
02-08-08, 05:11 PM
nospamatall <nospamatall@iol.ie> wrote in news:foigij$461$4@aioe.org:

....
> Thank you. Why is cryptography inhabited by such obnoxious anti-social
> twats?

Oh, I've embarrassed them multiple times in the past with their silly
errors, so they now keep coming back with childish attempts to catch me out
with their stupid cavils and quibbles every time I post. And so I have to
crush them yet again. Quite tiresome after the first few times, really.

Regards,

Sebastian G.
02-08-08, 06:08 PM
nemo_outis wrote:


> If that "other media" is permanently attached to the system (i.e.,
> "fixed") then plausible deniability is still shot. Since Microsoft only
> supports booting normal Windows (not PE, not embedded) from fixed media,
> what you want is unachievable with Windows as the OS (without violating
> the licence).


Once again: You can modify an normal Windows installation CD to allow
installation and booting from USB mass storage, FireWire Mass Storage and SD
Cards. Without any license violation. With a text editor and cabarc (which
is free to download from Microsoft).

> However, if you are still worried about plausible deniability (although
> there being a good reason for having a system that contains only disks
> with random data strikes me as the epitome of implausible)


Implausible? Heck, every media I buy is throughly tested by a very simple
yet highly effective scheme:

dd if=/dev/urandom bs=1m count=X | tee /dev/hdX | sha1sum
sync
dd if=/dev/hdX | sha1sum

If I never start using these media, then they will remain being filled with
pseudorandom data.

Ugh, and do you know what I do if I want to securely wipe media because I
plan to sell them? You can guess:

dd if=/dev/urandom bs=1m of=/dev/hdX

Sebastian G.
02-08-08, 06:11 PM
nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:613o84F1taan2U3@mid.dfncis.de:
>
>> nemo_outis wrote:
>>
>>
>>> If you have some argument to show how an unencrypted partition table
>>> would permit decrypting the contents of of an encrypted partition,
>>> then make it.
>>
>> It doesn't. What it permits is to differ the encrypted disc from
>> random data, and it permits knowledge about the partitioning of the
>> volume inside the encrypted container.
>
> But it is a limitation of Windows, not of Truecrypt or any other whole-disk
> OTFE program, that causes the difficulty.


Actually it is a limitation of TrueCrypt: It could actually encrypt the
partition table and decrypt it on the fly, it would just require a special
check for block 0 to not trying decrypt the MBR part and start decrypting at
the location of the partition table.

Additionally, if you do the pre-boot stuff, the MBR containing this code
would also differ from random data. But TrueCrypt does not permit storing
the MBR on another media and do some redirection.

Ari
02-08-08, 08:54 PM
On Fri, 08 Feb 2008 17:40:22 GMT, nemo_outis wrote:

> I'll be happy to post the method again if anyone cares.
>
> Regards,

I do.

I love you and you know that.
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

nemo_outis
02-08-08, 09:38 PM
"Sebastian G." <seppi@seppig.de> wrote in
news:61496qF1smtekU1@mid.dfncis.de:

> nemo_outis wrote:
>
>
>> If that "other media" is permanently attached to the system (i.e.,
>> "fixed") then plausible deniability is still shot. Since Microsoft
>> only supports booting normal Windows (not PE, not embedded) from
>> fixed media, what you want is unachievable with Windows as the OS
>> (without violating the licence).

> Once again: You can modify an normal Windows installation CD to allow
> installation and booting from USB mass storage, FireWire Mass Storage
> and SD Cards. Without any license violation. With a text editor and
> cabarc (which is free to download from Microsoft).


No, Sebastian, such a modification of Windows is not authorized by
Microsoft. But, if you are determined to do it anyway, then who am I to
stop you. Take the bit in your teeth, charge madly off, and behave as
rashly as you wish.

However, none of this reflects one bit on Truecrypt. Since you now have
your (unauthorized) USB boot drive, every other HD on the system could be
encrypted as a Truecrypt "superfloppy" that has absolutely everything
encrypted.

May you live happily with your system configured this way and no longer
pester others with your inanities.

And BTW, Sebastian, it's still utterly implausible that someone has a
computer system with every HD completely filled with random junk.

Remmember, Sebastian, it's not whether you find such patent nonsense
plausible but whether a judge and jury do.

Regards,

nemo_outis
02-08-08, 09:42 PM
"Sebastian G." <seppi@seppig.de> wrote in
news:6149deF1touudU1@mid.dfncis.de:

> nemo_outis wrote:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:613o84F1taan2U3@mid.dfncis.de:
>>
>>> nemo_outis wrote:
>>>
>>>
>>>> If you have some argument to show how an unencrypted partition
>>>> table would permit decrypting the contents of of an encrypted
>>>> partition, then make it.
>>>
>>> It doesn't. What it permits is to differ the encrypted disc from
>>> random data, and it permits knowledge about the partitioning of the
>>> volume inside the encrypted container.
>>
>> But it is a limitation of Windows, not of Truecrypt or any other
>> whole-disk OTFE program, that causes the difficulty.
>
>
> Actually it is a limitation of TrueCrypt: It could actually encrypt
> the partition table and decrypt it on the fly, it would just require a
> special check for block 0 to not trying decrypt the MBR part and start
> decrypting at the location of the partition table.

Truecrypt still has to put the bootstub on the boot HD, and that's a dead
giveaway that encryption is being used, no matter whether the partition
table is encrypted or not. Hell, the partition table being plaintext is
much more "vanilla."

> Additionally, if you do the pre-boot stuff, the MBR containing this
> code would also differ from random data. But TrueCrypt does not permit
> storing the MBR on another media and do some redirection.

Yes, Truecrypt has not COMPLETELY redesigned Windows' boot process to
accomodate a kook like you.

Regards,

nemo_outis
02-08-08, 10:15 PM
Ari <arisilverstein@yahoo.com> wrote in
news:1f1ux0vajj9g7.1i6hv3ciyph87.dlg@40tude.net:

> On Fri, 08 Feb 2008 17:40:22 GMT, nemo_outis wrote:
>
>> I'll be happy to post the method again if anyone cares.
>>
>> Regards,
>
> I do.
>
> I love you and you know that.



Here (from 2004) is the method whereby a suitably configured OS (or
powerful system-level program, etc.) could leak the encryption key of a
full-HD OTFE program without changing the encryption algorithm in the
least. My old description is in terms of DCPP but the method generalizes
to all such programs, including Truecrypt. All that is required is that
the full-HD OTFE user have installed a particular OS which has, say,
already been modifed back at Microsoft by the NSA to have the
capabilities I describe.




********************************************
A malign OS can leak the encryption key even while fully and perfectly
adhering to the DCPP encryption scheme. And it can leak the key on the
ordinary data areas of the HD - no hidey-holes required. The scheme will
pass every validation test, because it fully adheres to the DCPP
encryption rules.

AND YET THE KEY WILL HAVE BEEN LEAKED!
********************************************

Bear with me, for this is a little complicated to explain.

I'm going to describe the unobfuscated way of doing this at first.
First of all, I take as given that the malign OS can harvest the key from
memory. So the OS knows the key (say 256-bit for the sake of
concreteness)

Now, it is perfectly legitimate for the OS to write data for its own
purposes in a sequence of sectors (say as part of the swap file).
However, according to the DCPP encryption mechanism it must encrypt them
using the algorithm and key (and IV) that is prescribed by DCPP. So
here's what the malign OS does next.

Let's say the first 3 bits of the key are 001

For the first in a series of 256 consecutive sectors in the swap file
(and the OS can easily ensure these are also consecutive physical sectors
on the HD as well) the OS generates some random data. It then encrypts
it following the DCPP algorithm perfectly. If it encrypts to an odd 512-
byte number, the OS writes the sector. If it doesn't, it generates a new
random number and tries again. Very quickly it finds a value that will
encrypt to an odd 512-byte number. Satisfied, it writes the data to the
sector. Here's the crux: the OS has just written a sector that can be
interpreted as a binary zero (i.e., if the whole 512-byte encrypted
sector is odd). It has just leaked the first bit of the key!

The OS repeats the process for the next sector until it again writes what
can be interpreted as a "zero" (i.e., the whole 512-byte encrypted sector
is odd). It has just leaked the second bit of the key!

The OS repeats the process again for the third bit - except this time the
sector must encrypt to an even 512-byte number to signal a binary one.
The OS writes the sector, thus leaking the third bit of the key.

And so on and so on until the OS has leaked the entire 256-bit key as a
sequence of 256 consecutive completely-properly-encrypted sectors, with
each sector interpreted as binary 0 or 1 according to whether its whole
512-byte contents are even or odd!

But how would someone looking at the disk know where the OS has leaked
the key? Answer: the OS uses (say) a ten-sector sequence of all evens
(say) to signal that the next 256 sectors should be interpreted as the
key!

Result: the malign OS has fully conformed to the encryption rules. Every
sector is correctly encrypted according to the rules - no exceptions! No
data has been written to any hidey-hole. AND YET THE KEY HAS BEEN
LEAKED!

Assuming you understand the above, you can now add obfuscation. For
instance, there is no need for the "key follows" signal to be ten 1's -
it could just as easily be 1001001101110111.

Similarly, the malign OS needn't leak the key as "plaintext" - it can
encrypt/obscure the leaked key sequence using a prearranged scheme known
only to the NSA and Microsoft.

As I said in a previous post: Covert channels are a bitch to plug!

Regards,

PS Needless to say, once the principle is grasped, zillions of
variants readily spring to mind.

Ari
02-08-08, 10:26 PM
On Fri, 08 Feb 2008 15:58:52 GMT, nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:613aivF1ti8nnU1@mid.dfncis.de:
>
>> nemo_outis wrote:
>>> Superfloppyish-based encrypted storage is only suitable for data
>>> storage, not for a bootable Windows system. In fact, independent of
>>> any encryption aspects, Windows has been deliberately crippled so it
>>> can NOT boot/run from removable media such as superfloppies
>>> (Microsoft says it's a licencing issue).
>
>> Nonsense. Microsoft has only disabled this option by default, since
>> they don't want to support such configurations.
>
> Ahh, that's more like it. I feel much better when Sebastian reverts to
> his old self and spouts ********. The world is running as expected.

munch munch munch munch

Hilda, bring the ****ing beer, will ya', it's heating up in here!!
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

Ari
02-08-08, 10:31 PM
On Fri, 08 Feb 2008 21:11:48 +0000, nospamatall wrote:

> Why is cryptography inhabited by such obnoxious anti-social
> twats?

Live your life inside of extraterrestrial symbols and algorithmic heaven
and see if you can get a hard on.
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

Ari
02-08-08, 10:32 PM
On Fri, 08 Feb 2008 23:11:49 GMT, nemo_outis wrote:

> Oh, I've embarrassed them multiple times in the past with their silly
> errors, so they now keep coming back with childish attempts to catch me out
> with their stupid cavils and quibbles every time I post. And so I have to
> crush them yet again. Quite tiresome after the first few times, really.

So you're on amphetamines?

Got it.

munch munch munch munch
--
An Explanation Of The Need To Be "Anonymous"
http://www.penny-arcade.com/comic/2004/03/19

Anonymous
02-08-08, 11:31 PM
Sebastian G. wrote:

> Cyberiade.it Anonymous Remailer wrote:
>
>
> >> 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.
> >
> > Problem is, with Truecrypt you don't have that choice.
>
>
> So then my fully encrypted harddisk with even an encrypted partition table
> is pure imagination?

It sure as hell is if you think you have a usable operating system
installed on it.

>
> > Go ahead and try it. Encrypt an entire drive and see if you can
> > install an OS to it.
>
>
> Who cares for installing an OS? This drive only contains data, the OS is on
> another media.

Exactly. That's what tells us you're using partition/volume encryption
rather than whole disk encryption.

I have no idea where you're getting your definitions and information
from, or whether you're just making **** up as you go, but even
Truecrypt doesn't claim to be whole disk encryption.

Do you really think you're more knowledgeable about the product than the
people who write and maintain it? Are you that self deluded?

Anonymous
02-08-08, 11:41 PM
nemo_outis wrote:

<snip>

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

<snip>

None of that has anything at all to do with what the guy was
talking about. Nobody is even suggesting the use of Truecrypt would
be hidden, he's talking about hardening Truecrypt's plausible
deniability by using hidden volumes to create two completely
separate encrypted OS installs, and using the password mechanism as
a sort of boot loader. Is such a thing possible?

Please..... if you don't understand the question don't try and give
an answer.

Anonymous
02-08-08, 11:54 PM
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.

You didn't find ****. There's no such vulnerability that hasn't
been fixed, and all you're doing is spreading FUD to try and make
yourself look important. You've pulled that same crap before too,
and got spanked right out of a couple forums because of it.

Isn't that right, "Gobbleslop"? ;-)

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

It aint NOTHING like PGPWHoleDisk.


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

Anonymous
02-09-08, 12:03 AM
nemo_outis wrote:

> 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're not correct, and you're own waffling words prove it....

> 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

Yes, you've encrypted the **whole drive** with noted exceptions, but not
the "whole disk" as a contiguous piece of real estate as true whole disk
encryption tools do (including the partition table). Even you realize
this, and stated so in spite of your continued argumentative tone and
hurling of insults. There is a difference, and you've been provided
cites and examples to show why for some people this may be an issue. No
amount of quibbling over your queer interpretations of terms can change
that, or the fact that even Truecrypt acknowledges the difference.

Anonymous
02-09-08, 12:05 AM
Phil Carmody wrote:

> Casper <spam@spam.spam> writes:
> > >
> > > Who cares for installing an OS? This drive only contains
> > > data, the OS is on another media.
> >
> > LOL LOL LOL >:|
> >
> > You will never understand what we are talking about.
> > Maybe your posts should not appear in alt.privacy at all
> > I am putting up a filter.
>
> Anything which separates alt.privacy from sci.crypt is
> a good thing. Keeping your ill-thought-out gibberings
> off sci.crypt would in particular be appreciated.

You could always try alt.whining.cunts.moderated.

It's that way ------------------------------------->