Truecrypt 5.0 Released (now with system partition encryption)

nemo_outis wrote:

> Anonymous <nobody@aes256.cn> wrote in
> news:467a6c3e67d87672537f410df031956d@aes256.cn:
>
> No, Windows boots from the system drive.


Actually this is a bit confusing, since Microsoft accidentally swapped these
two terms. That is, the boot loader is stored on the "System Drive" and
Windows itself is stored on the "Boot Drive". And the variable %SYSTEMDRIVE%
points to where Windows is stored...

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:616nm0F1thrluU3@mid.dfncis.de:
>
> Micrsoft ionly supports Windows booting from the system disk - anything
> else is a hack.


Nonsense. Microsoft supports staged boot loading very well, and it doesn't
require any hack. There's absolutely no problem installing GRUB, GRUB loads
the Windows boot sector which in turn load NTLDR and so on.

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:616o5pF1thrluU6@mid.dfncis.de:
>
>> nemo_outis wrote:
>>
>>> Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it>
>>> wrote in news:24250861f8cfd5a440460111e28b78d8@remailer.cyb eriade.it:
>>>
>>> Windows cannot boot from a completely encrypted disk because there's
>>> nothing to decrypt those first bytes to even get the process started.
>> This decryption can be provided by an additional, removal media. The
>> media only decrypts the the boot loader mini driver, which is turn
>> will decrypt the relevant files, boot up the Windows kernel and pass
>> over control to the actual decryption driver.
>>
>> TrueCrypt does not support this scheme. PGP Whole Disk Encryption
>> does, and some other claim to do so as well.
>
> Yes, but this is a hack of Windows, Sebastian.


Why should this be a hack? It's staged boot loading, which has been a
trivial thing since ever.

> And, of course, one can do adiitional hacks so that the initialization
> code on one device (e.g., a USB stick) hands off the rest of Windows
> operation to a separate volume (commonly a RAM disk, but potentially a
> HD).


You're handing over the boot record, nothing else.

> But these are hacks of Windows, Sebastain - completely unsupported.

So it's a pure wonder that the Windows supports booting DOS?

anonymous@remailer.hastio.org wrote:


>>>> it spotlights why OTP is considered
>>>> the only truly unbreakable form of encryption. If a ciphertext can
>>>> potentially be "anything", it's impossible to even know if you've
>>>> successfully decrypted it or not. ;)
>>>
>>> OTP's security comes from the fact that knowing the message doesn't change
>>> the a priory probability of the plaintext. It never claimed that all
>>> plaintexts are equally likely.
>> No, that's EXACTLY what H(M) = H(M | C) means, if you actually
>> understand it. Since a priory probability and a posteriori probability
>> are equal a given ciphertext could in fact decrypt to... anything.
>> Given the appropriate pad of course.


I'll give you a counter example:

encryption:
- if the plaintext is "Nomen Nescio understands OTP", then stop and fail
- generate a random stream as long as the plaintext, it's the key
- add them, you get the ciphertext

decryption:
- subtract key from ciphertext
- if the plaintext is "Nomen Nescio understands OTP", then stop and fail
- otherwise it's the plaintext

This scheme is, by definition above, a OTP. Yet the plaintext "Nomen Nescio
understands OTP" is impossible and no ciphertext can decrypt to this.

anonymous@remailer.hastio.org wrote:


>>>> >>>> it spotlights why OTP is considered
>>>> >>>> the only truly unbreakable form of encryption. If a ciphertext can
>>>> >>>> potentially be "anything", it's impossible to even know if you've
>>>> >>>> successfully decrypted it or not. ;)
>>> >>>
>>> >>> OTP's security comes from the fact that knowing the message doesn't
change
>>> >>> the a priory probability of the plaintext. It never claimed that all
>>> >>> plaintexts are equally likely.
>> >> No, that's EXACTLY what H(M) = H(M | C) means, if you actually
>> >> understand it. Since a priory probability and a posteriori probability
>> >> are equal a given ciphertext could in fact decrypt to... anything.
>> >> Given the appropriate pad of course.


I'll give you a counter example:

encryption:
- if the plaintext is "Nomen Nescio understands OTP", then stop and fail
- generate a random stream as long as the plaintext, it's the key
- add them, you get the ciphertext

decryption:
- subtract key from ciphertext
- if the plaintext is "Nomen Nescio understands OTP", then stop and fail
- otherwise it's the plaintext

This scheme is, by definition above, a OTP. Yet the plaintext "Nomen Nescio
understands OTP" is impossible and no ciphertext can decrypt to this.



As a suggestion for fixing your definition:

For every *possible* plaintext the number of keys which decrypt a given
ciphertext to this plaintext are the same.

\exist d=const \forall p,c |K|=d | \forall k \iselem K dec(c,k)=p

bealoid wrote:

> George Orwell <nobody@mixmaster.it> wrote in
> news:c55c038c9722894a88f01af8c6244801@mixmaster.it :
>
>> nemo_outis wrote:
>>
>>> Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it> wrote
>>> in news:24250861f8cfd5a440460111e28b78d8@remailer.cyb eriade.it:
>>>
>>> Windows cannot boot from a completely encrypted disk because there's
>>> nothing to decrypt those first bytes to even get the process started.
>> Wanna bet? If I post a link that proves Windows can boot
>> from a 100% encrypted device, including the MBR, WITHOUT
>> using any other software or copying any information at
>> all to or from anywhere, will you put on your clown suit
>> and dance for us, then leave?
>
> I'm not that person, but I'd be interested to see the link please.
>
> How secure is ATA Disk encryption? There seem to be many tools to unlock
> discs.


So far any implementation I've seen used ECB mode, thus is way worse than an
serious software implementation with only the MBR and the partition table
exposed.

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

You still don't understand. Reread what Bestcrypt has to say again.

Regards,

Nomen Nescio <nobody@dizum.com> wrote in
news:424d41c3a928e32ff32a6de3233c124a@dizum.com:

If you can show how an unencrypted partition table can be used to decrypt
the drive's contents, do so. If not, STFU.

Regards,

You continue not to understand what Bestcrypt says.

Regards,

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

You're still blithering?

Regards,

If you have something to say, say it. Otherwise STFU.

Regards,

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

> nemo_outis wrote:
>
>> Anonymous <nobody@aes256.cn> wrote in
>> news:467a6c3e67d87672537f410df031956d@aes256.cn:
>>
>> No, Windows boots from the system drive.
>
>
> Actually this is a bit confusing, since Microsoft accidentally swapped
> these two terms. That is, the boot loader is stored on the "System
> Drive" and Windows itself is stored on the "Boot Drive". And the
> variable %SYSTEMDRIVE% points to where Windows is stored...

And manipulating those pointers is one way to get a USB stick to boot and
pass control to most of Windows that is typically stored in RAM. However,
it's an unsupported hack.

Regards,

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

> nemo_outis wrote:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:616nm0F1thrluU3@mid.dfncis.de:
>>
>> Micrsoft ionly supports Windows booting from the system disk -
>> anything else is a hack.
>
>
> Nonsense. Microsoft supports staged boot loading very well, and it
> doesn't require any hack. There's absolutely no problem installing
> GRUB, GRUB loads the Windows boot sector which in turn load NTLDR and
> so on.

No, that's an hack, unsupported by Microsoft.

Regards,

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

> nemo_outis wrote:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:616o5pF1thrluU6@mid.dfncis.de:
>>
>>> nemo_outis wrote:
>>>
>>>> Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it>
>>>> wrote in news:24250861f8cfd5a440460111e28b78d8
@remailer.cyberiade.it:
>>>>
>>>> Windows cannot boot from a completely encrypted disk because there's
>>>> nothing to decrypt those first bytes to even get the process
started.
>>> This decryption can be provided by an additional, removal media. The
>>> media only decrypts the the boot loader mini driver, which is turn
>>> will decrypt the relevant files, boot up the Windows kernel and pass
>>> over control to the actual decryption driver.
>>>
>>> TrueCrypt does not support this scheme. PGP Whole Disk Encryption
>>> does, and some other claim to do so as well.
>>
>> Yes, but this is a hack of Windows, Sebastian.
>
>
> Why should this be a hack? It's staged boot loading, which has been a
> trivial thing since ever.

I didn't say it was difficult, Sebastian, I said it was an unsupported
hack. And so it is.

Regards,

You still don't understand what Bestcrypt is saying. Reread it again.

Regards,

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

Actually no.

Regards,

nemo_outis wrote:

> Nomen Nescio <nobody@dizum.com> wrote in
> news:424d41c3a928e32ff32a6de3233c124a@dizum.com:
>
> If you can show how an unencrypted partition table can be used to decrypt
> the drive's contents, do so. If not, STFU.


He doesn't have to. The mere fact that the partition table is unencrypted is
a violation of the security goal.

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:6187vmF1tdk23U4@mid.dfncis.de:
>
>> nemo_outis wrote:
>>
>>> Anonymous <nobody@aes256.cn> wrote in
>>> news:467a6c3e67d87672537f410df031956d@aes256.cn:
>>>
>>> No, Windows boots from the system drive.
>>
>> Actually this is a bit confusing, since Microsoft accidentally swapped
>> these two terms. That is, the boot loader is stored on the "System
>> Drive" and Windows itself is stored on the "Boot Drive". And the
>> variable %SYSTEMDRIVE% points to where Windows is stored...
>
> And manipulating those pointers is one way to get a USB stick to boot and
> pass control to most of Windows that is typically stored in RAM. However,
> it's an unsupported hack.


There is no need to do so. Just let the boot loader on any external media
load the Windows boot loader (when Windows is stored on the disc) and
transfer control to it. This is known as boot staging and has been done
since over thirty years, is absolutely nothing special and requires no
manipulation.

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:61883qF1tdk23U5@mid.dfncis.de:
>
>> nemo_outis wrote:
>>
>>> "Sebastian G." <seppi@seppig.de> wrote in
>>> news:616nm0F1thrluU3@mid.dfncis.de:
>>>
>>> Micrsoft ionly supports Windows booting from the system disk -
>>> anything else is a hack.
>>
>> Nonsense. Microsoft supports staged boot loading very well, and it
>> doesn't require any hack. There's absolutely no problem installing
>> GRUB, GRUB loads the Windows boot sector which in turn load NTLDR and
>> so on.
>
> No, that's an hack, unsupported by Microsoft.

http://en.wikipedia.org/wiki/Booting...ge_boot_loader

nemo_outis wrote:


> I didn't say it was difficult, Sebastian, I said it was an unsupported
> hack. And so it is.


It's not a hack, since nothing is manipulated.

nemo_outis wrote:


> No, that's an hack, unsupported by Microsoft.


http://en.wikipedia.org/wiki/Chain_l...nager_programs

And it's no hack since it doesn't require any modifications. heck, it's even
a part or the IBM PC / PS/2 specification.

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

> nemo_outis wrote:
>
>> Nomen Nescio <nobody@dizum.com> wrote in
>> news:424d41c3a928e32ff32a6de3233c124a@dizum.com:
>>
>> If you can show how an unencrypted partition table can be used to
>> decrypt the drive's contents, do so. If not, STFU.
>
>
> He doesn't have to. The mere fact that the partition table is
> unencrypted is a violation of the security goal.

Whose goal? And why?

Regards,

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

> There is no need to do so. Just let the boot loader on any external
> media load the Windows boot loader (when Windows is stored on the
> disc) and transfer control to it. This is known as boot staging and
> has been done since over thirty years, is absolutely nothing special
> and requires no manipulation.

Peachy! And what the hell will this Windows boot loader then do when all
the HDs on the system (possibly including track zero) are encrypted?

Regards,

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

Peachy! Except:

1) Microsoft does not support others' boot loaders, and
2) the Windows boot sector, NTLDR, and the rest are all sitting encrypted
on the HDs.

Regards,

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

> nemo_outis wrote:
>
>
>> I didn't say it was difficult, Sebastian, I said it was an unsupported
>> hack. And so it is.
>
>
> It's not a hack, since nothing is manipulated.

It is a hack since Microsoft doesn't support it.

Regards,

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

> nemo_outis wrote:
>
>
>> No, that's an hack, unsupported by Microsoft.
>
>
> http://en.wikipedia.org/wiki/Chain_l...in_boot_manage
> r_programs
>
> And it's no hack since it doesn't require any modifications. heck,
> it's even a part or the IBM PC / PS/2 specification.

It is a hack since Microsoft doesn't support it.

Wanna go round again?

Regards,

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in news:618k83F1tb8hhU4
> @mid.dfncis.de:
>
>> nemo_outis wrote:
>>
>>
>>> I didn't say it was difficult, Sebastian, I said it was an unsupported
>>> hack. And so it is.
>>
>> It's not a hack, since nothing is manipulated.
>
> It is a hack since Microsoft doesn't support it.


Well, couldn't you tell us that your stupid way earlier?

nemo_outis wrote:

> "Sebastian G." <seppi@seppig.de> wrote in
> news:618k32F1tb8hhU2@mid.dfncis.de:
>
>> There is no need to do so. Just let the boot loader on any external
>> media load the Windows boot loader (when Windows is stored on the
>> disc) and transfer control to it. This is known as boot staging and
>> has been done since over thirty years, is absolutely nothing special
>> and requires no manipulation.
>
> Peachy! And what the hell will this Windows boot loader then do when all
> the HDs on the system (possibly including track zero) are encrypted?


Working exactly the same way as the pre-boot stuff?

nemo_outis wrote:


> It is a hack since Microsoft doesn't support it.
>
> Wanna go round again?


If you're expecting anything but a *PLONK* then you're even more stupid than
you've already presented yourself so far.

nemo_outis, the dirty mail address faker wrote:

> > It is a hack since Microsoft doesn't support it.
> >
> > Wanna go round again?

If you're expecting anything but a *PLONK* then you're even more stupid than
you've already presented yourself so far.