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,