Truecrypt 5.0 Released (now with system partition encryption)

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

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.

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 bullshit. The world is running as expected.

munch munch munch munch

Hilda, bring the fucking 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

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

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

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

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.

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

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.

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

nobody@aes256.cn (Anonymous) wrote in news:f0c6f944956a469714d047cbab689929
@aes256.cn:

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


I understand the question very well.

And my answer is twofold:

1) I cannot currently be done with Truecrypt

2) That it cannot be done is no loss since it's a silly idea in the first
place.

Regards,

Anonymous <nobody@aes256.cn> wrote in
news:874c4fbd4874eb652c39433b31131c8a@aes256.cn:

> nemo_outis wrote:

If you encrypt an entire HD (as Truecrypt allows you to do in "device"
mode) then you cannot boot from that HD. If you do this with all your HDs
then you cannot boot from any of them. You are reduced to using all your
HDs as data drives. And so you must find something else (CD, USB, etc) to
boot from. Or else stare at your completely non-functional computer, which
will just sit there making exactly the same kind of humming noise that
bricks don't.

If this was all you wanted from life then you could have stuck with version
4.3 of Truecrypt, and not bothered folks here with your whinging.

Regards,

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


Excuse me dumbass, but.... Bestcrypt isn't wholedisk encryption
either.

Main Features

1. Encrypting all types of volumes residing on fixed and removable disks:
* Simple volume, i.e. volume consisting of one disk partition.
* Mount point - volume mounted as a sub-folder on NTFS-formatted volume.
* Multipartition volume, i.e. volume consisting of several disk partitions:
1. Spanned volumes;
2. Mirrored volumes;
3. Striped volumes;
4. RAID-5 volumes.

If you're struggling with the meaning of "volume" and "residing
on" let us know and we'll post some explanations using really
small words. :)


> 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

What a crock. Do you have any clue at all how many wholedisk OTFE
producte actually DO encrypt the partition table? Any clue at all?

Wait, no you don't. You don't even know what wholedisk encryption
products ARE.

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

That's really funny coming from someone whose idea of "secure" is
hiding something in a sock drawer.

Yeah nimrod, your silly ass steganography is secure but hiding the
fact that entire partitions exist with strong encryption is a waste
of time.

You're not just dim, you can't even pick a position and stick with
it.

What an idiot.

Thanks, nemo.


On Sat, 09 Feb 2008 04:15:24 GMT, nemo_outis wrote:

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


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

nemo_outis wrote:

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

"BestCrypt Volume Encryption software provides the following advanced
functionality:

1. Encrypting all types of volumes residing on fixed and removable
disks:

* I. Simple volume, i.e. volume consisting of one disk partition.
* II. Mount point - volume mounted as a sub-folder on
NTFS-formatted volume.
* III. Multipartition volume, i.e. volume consisting of several
disk partitions:"

http://www.jetico.com/bcve_web_help/...n_features.htm

What part of "volume" and "residing on" are you struggling with there
sonny? :)

Anonymous 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.
>
> You didn't find SHIT. 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.


Since the TrueCrypt developers obviously don't care (haven't responded
withing 48 hours), I can publish the vulnerability:

ntdriver.c!ProcessVolumeDeviceControlIrp!IOCTL_MOU NTDEV_QUERY_SUGGESTED_LINK_NAME:
if Irp->AssociatedIrp.SystemBuffer is smaller than
sizeof(MOUNTDEV_SUGGESTED_LINK_NAME), this will lead to an unhandled invalid
memory write access or kernel memory corruption. If the buffer address is
larger than 0x100000000-sizeof(MOUNTDEV_SUGGESTED_LINK_NAME), an integer
overflow occurs and allows to write into memory regions around 0x00000000 to
(sizeof(MOUNTDEV_SUGGESTED_LINK_NAME)), where the process control block may
reside

ntdriver.c!ProcessVolumeDeviceControlIrp!IOCTL_DIS K_VERIFY: if if
Irp->AssociatedIrp.SystemBuffer is smaller than sizeof(VERIFY_INFORMATION),
this will lead to an unhandled invalid memory read access or information
disclosure

Both can easily be triggered by creating a new volume or taking an existing
one, mounting it with drive letter X: and the running dc2.exe (Driver Path
Exerciser Tool for the Windows Driver Kit) against the volume object file:
"dc2 /hct \Device\TrueCryptVolumeX". If you activate logging (switch '/lv'),
then you'll see that the crash happens for the DeviceIoControl test at the
IOCTLs 0x4d00c or 0x70014, which are the two mentioned above.

> You've pulled that same crap before too,
> and got spanked right out of a couple forums because of it.


I only posted one vulnerability in the forums, which was a real
vulnerability (the Makefile for the driver defined the macro NT_UP=1, which
will trigger some optimization for single processor systems that don't hold
on multi processor systems and lead to fatal consequences) and this got
acknowledged quite well. Being "spanked right out" is something I don't know
about, maybe you can elaborate?

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


Hm? Should this name tell me anything?

nemo_outis wrote:

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


Such a modification is even explicitly intended by Microsoft, it's called an
"unattended setup".

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


I already told you some counterexamples.

> Remmember, Sebastian, it's not whether you find such patent nonsense


OK, now you even call standard practices nonsense.

> plausible but whether a judge and jury do.


They should. After all, any special attended expert can tell them that such
things are common practice.

nemo_outis wrote:


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


Two obvious things:

- This is not a limitation of Windows' boot process. Why do you think it is?

- storing the initial boot loader on another media to avoid running a
potentially modified bootloader from the disk in neither unknown nor
unusual, so it's no wonder that some products actually implement this

But since you can hardly do anything but ranting, maybe you should stop
discussing about such trivialities.

Anonymous wrote:

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


I don't think so, since I haven't. And never claimed so.


Maybe you have a problem with statements? The I'll better summarize the
current point:

- TrueCrypt does support encrypting entire media including partition tables,
so it's FDE.
- TrueCrypt does support booting from encrypted partitions using pre-boot
authentication.
- But not oth things simultaneously on the same media.

>> 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 use partition encryption for the OS, and FDE volume encryption for the data.

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


It does claim so, supports it very well and I can easily verify on my system
that it actually does.

> Do you really think you're more knowledgeable about the product than the
> people who write and maintain it?


No. I just think that you're too stupid to read the documentation and/or try
it yourself - before posting your spouted nonsense.

Anonymous <nobody@aes256.cn> wrote in
news:3d153c86fd7dcfae05dfaafa24ca4363@aes256.cn:

You still don't understand that Bestcrypt Volume Encryption can provide
OTFE protection for full HDs? Then go read the site documentation again -
maybe this time even a moron like you will get it.

Regards,

nobody@aes256.cn (Anonymous) wrote in
news:6820499054317f6d4743e40c24032cb3@aes256.cn:

You still don't understand that Bestcrypt Volume Encryption can provide
OTFE protection for full HDs? Then go read the site documentation again -
maybe this time even a moron like you will get it.

Regards,

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

> Such a modification is even explicitly intended by Microsoft, it's
> called an "unattended setup".

It's not the unintended setup that's unsupported ny Microsoft, but setup to
a removable drive (e.g., USB)

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

> I already told you some counterexamples.

Yes, blatantly implausible ones.

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

No, Sebastian, by far the most plausible reason for every drive on a
computer being filled with random junk is that encryption is being used.

Regards,

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

> nemo_outis wrote:
>
>
>>> 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.
>
>
> Two obvious things:
>
> - This is not a limitation of Windows' boot process. Why do you think
> it is?
>
> - storing the initial boot loader on another media to avoid running a
> potentially modified bootloader from the disk in neither unknown nor
> unusual, so it's no wonder that some products actually implement this

How can you be this stupid, Sebastian? No matter how easy you think it
is, no matter how badly you want it, the plain fact of the matter is that
WINDOWS DOESN'T DO IT!

Regards,

nemo_outis wrote:

> 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

Nobody ever said anything at all like that you lying asshole.
You've already been clubbed over the head with a cite about why
unencrypted partition tables are less secure than encrypted ones.
You didn't even have the courage to reply to it, but it's out there
none the less.

> partition, then make it. If not, then, as I have repeatedly
> suggested: Do be a good little moron and fuck off.
>
> Regards,

nemo_outis wrote:

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

I almost feel sorry for you. Even you had to cringe when you made the
decision to try and float such a whopper.

*snicker*

Nobody is going to buy it liar. If you're going to play that way you're
going to at least play on some level above "imbecile". Come up with a
credible lie. Maybe "Oh, they must have just changed that page when
they released 5.0" or something. It wouldn't really help all that much
because the link you provided says exactly the opposite of the lie you
tried to tell, but at the bottom end of the evolutionary ladder you
would, at least, stand out among your peers.

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

What they say, "moron", is that volume, partition, and FD/Wholedisk are
three different things. Period. And that of those three possibilities,
Bestcrypt is clearly of type "volume". Period. It's not ambiguous no
matter how hard you try and wriggle out of you own imbecility by
pretending it is. It's a clear statement of fact that proves you
unequivocally wrong, made by the people you were "citing" in an attempt
to prop up that imbecility.

Sorry about your luck, sucks to be you, have a nice day.

*snicker*

> Now do be a good moron and fuck off.

Maybe after a bit. That crunching sound is just too attractive at the
moment. Sorta like a little symphony, being backed up your your
squealing and all.

*snicker*

Don't worry little one, I know how important it is for people like you
to get the last word in. When I decide that time has come, I'll let you
know. :)

Sebastian G. wrote:

> 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

Which doesn't matter one fucking bit because unless it's mounted,
it's encrypted.

What an idiot.


> 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 <nobody@dizum.com> wrote in
news:9c560c5e4d435ab2734ae2e076739ea3@dizum.com:

Back again with the same bullshit? You get the same answer as last time.

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

Regards,

Nomen Nescio <nobody@dizum.com> wrote in
news:82ea57176532ddf0881ca98427937d4a@dizum.com:

You obviously still haven't enrolled in that remedial reading course.

Regards,

nemo_outis wrote:

> 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

Wrong!

Windows can trivially boot from a completely, 100% end to end including
sector 0, encrypted drive without modifying Windows at all, without
using any external bootstrapping at all, and without using any stupid
"boot sector copying" scheme.

Your problem is your narrow little mind sonny. Ponder it a bit longer
for my amusement and then I'll give you the facial. :)

nemo_outis wrote:

> nobody@aes256.cn (Anonymous) wrote in news:f0c6f944956a469714d047cbab689929
> @aes256.cn:
>
> > 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.
>
>
> I understand the question very well.
>
> And my answer is twofold:
>
> 1) I cannot currently be done with Truecrypt
>
> 2) That it cannot be done is no loss since it's a silly idea in the first
> place.

So you're saying Truecrypt's hidden volumes are a silly idea?

Fascinating.

Oh wait, you're just being a vindictive little snipe because you got
your ass handed to you over your Bestcrypt foible, and you mistakenly
though you were striking back. You know full well the ability to create
a "hidden system" volume would be near perfect plausible deniability
because by the very definition of hidden volume as Truecrypt provides,
it would be impossible to know if/where that volume existed, and not
having the "host" volume mounted at all would mean nothing could leak
to that copy of an OS across the encrypted boundrary. Additionally, the
two password scheme used by normal hidden volumes would both protect
the hidden volume, and provide a sort of "dead man" that could easily
destroy the hidden evidence through normal use of the host volume.

Pitty such a poetically secure isn't possible. Or is it? Did you
actually try it, or is this just another nemo_outhouse crapper load of
guesses and wishes?