http://www.truecrypt.org/

Regards,

nemo_outis wrote:
Anyone tried it? Is it whole disk encryption like PGP whole disk encryption?

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

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

Regards,

Merk wrote:

Merk wrote:


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

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


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

nospamatall wrote:


Everything except the boot loader.

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

Casper wrote:
the entire disk is encrypted, how could you do anything with it?

Andy

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

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


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

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

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

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

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

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

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

Regards,

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

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

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

nospamatall wrote:

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.

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

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

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

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

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

Regards,

nemo_outis wrote:

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

It's not quibbling and whining, it's called being accurate. The two
types of encryption being discussed here don't even function at the
same layer. Whole disk is "storage layer"[2] encryption and
Ttruecrypt obviously does business at the file system layer.

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

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

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

Il mittente di questo messaggio|The sender address of this
non corrisponde ad un utente |message is not related to a real
reale ma all'indirizzo fittizio|person but to a fake address of an
di un sistema anonimizzatore |anonymous system
Per maggiori informazioni |For more info
https://www.mixmaster.it

Cyberiade.it Anonymous Remailer wrote:

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

Ari wrote:


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

Ari wrote:

In a similar vein, the Linux version sucks.

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

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

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

Sebastian G. wrote:

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.

On Feb 7, 1:45*am, Anonymous <x...@hermetix.org> wrote:
http://www.geocities.com/moparholick/index.html