I have two questetions about DriveCrypt Power Pack. I have encrypted my
system partition (C) and my data partition (D) and my external harddisk (E),
which I use for making backups. Booth authentification is on and I have
created a rescue floppy.
1. Now I was wondering what I should have done in case of the following
situation: suppose my computer is stolen and the only thing that is left is
my encrypted external harddisk. When I connect this harddisk to another
computer, install DCPP and import the (exported) key, is this sufficient for
decrypting my external harddisk? Or should I have backuped the entire
keystore?
2. Does the keystore have to be located on the encrypted system partition or
can it also be located on the encrypted data partition (D)? I can imagine
the if I locate it on the encrypted D drive, booth authentification cannot
read the keystore and the system won't start. Or am I wrong and can the
keystore be locaed anywhere?
Sebastian Gottschalk wrote:
> Peter wrote:
>
>> Hello,
>>
>> I have two questetions about DriveCrypt Power Pack. I have encrypted my
>> system partition (C) and my data partition (D) and my external harddisk (E),
>> which I use for making backups. Booth authentification is on and I have
>> created a rescue floppy.
>>
>> 1. Now I was wondering what I should have done in case of the following
>> situation: suppose my computer is stolen and the only thing that is left is
>> my encrypted external harddisk. When I connect this harddisk to another
>> computer, install DCPP and import the (exported) key, is this sufficient for
>> decrypting my external harddisk? Or should I have backuped the entire
>> keystore?
>
> Who knows? Read the documentation and ask the vendor. Generally, the answer
> seems to be: No, almost all of these software packages are totally fucked
> up and add some random information that you'll lose.
>
>> 2. Does the keystore have to be located on the encrypted system partition or
>> can it also be located on the encrypted data partition (D)? I can imagine
>> the if I locate it on the encrypted D drive, booth authentification cannot
>> read the keystore and the system won't start.
>
> Now that's a trivial conclusion.
>
>
> Anyway, who cares? You're running DriveCrypt, thus the encryption is just a
> worthless additional transformation of your data. Brute-forcing the key by
> attacking the key-generation scheme or some other flaw in the
> implementation has usually been very successful against this crappy
> software.
> Who knows? Read the documentation and ask the vendor. Generally, the
> answer
> seems to be: No, almost all of these software packages are totally fucked
> up and add some random information that you'll lose.
> Anyway, who cares? You're running DriveCrypt, thus the encryption is just
> a
> worthless additional transformation of your data. Brute-forcing the key by
> attacking the key-generation scheme or some other flaw in the
> implementation has usually been very successful against this crappy
> software.
Thank you for your helpful contribution. I know a lot more now...
Sebastian Gottschalk wrote:
> Notan wrote:
>
>>> Brute-forcing the key by
>>> attacking the key-generation scheme or some other flaw in the
>>> implementation has usually been very successful against this crappy
>>> software.
>> Cites?
>
> Is your Google broken?
>
> Anyway, even Mr. Schneier tells so.
I simply asked for cites.
The old "If you don't know, I'm not going to tell you" line is
one of the oldest, and most childish, arguments on the block.
Peter <hello@hello.hello> wrote:
> I have two questetions about DriveCrypt Power Pack.
What do SecureStar say?
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk <seppi@seppig.de> wrote:
[about DriveCrypt]
> Anyway, who cares? You're running DriveCrypt, thus the encryption is just a
> worthless additional transformation of your data.
Do you have any proof of these claims?
Unfortunately, SecureStar only have advertizing nonsense about their
product DriveCrypt on their website:
| 1344 Bit Military Strength disk encryption using the best and most
| proven cryptographic algorithms such as AES, Blowfish, Tea 16, Tea 32,
| Des, Triple Des, Misty 1 and Square.
Nonsense.
But advertizing nonsense is very common, and maybe this product is good
nevertheless.
What exactly is your problem with DriveCrypt?
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Notan wrote:
> >> Brute-forcing the key by
> >> attacking the key-generation scheme or some other flaw in the
> >> implementation has usually been very successful against this crappy
> >> software.
> > Cites?
> Is your Google broken?
Mine seems to be b0rken, too.
DriveCrypt and TrueCrypt both are derivates of E4M. What is your problem
with DriveCrypt?
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk <seppi@seppig.de> wrote:
> The implementation of the key generation and key management. We've seen the
> plain keys being dumped to the swap file, we've seen the entropy collection
> reducing itself to about 40 bits of entropy...
Proofs for these claims?
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Just encrypt something with DriveCrypt and run a program with high memory
> consumption in parallel. Most likely, the plain encryption key will end up
> in your swap file.
Nice. But not significant, because no-one will handle this like that.
> > Unfortunately, SecureStar only have advertizing nonsense about their
> > product DriveCrypt on their website:
> >| 1344 Bit Military Strength disk encryption using the best and most
> >| proven cryptographic algorithms such as AES, Blowfish, Tea 16, Tea 32,
> >| Des, Triple Des, Misty 1 and Square.
> > Nonsense.
> Nah, the 1344 bit aren't nonesense. It's Triple-BlowFish, even though it
> would have an effective security of 896 bits at best.
There is no "Triple-BlowFish" in the text above, so the text remains
nonsense. And: more than 256bit with a secure block cypher is nonsense, too.
> And at least AES, BlowFish, 3DES and Square are best proven. The rest is
> trivially broken.
Nonsense, yes. Even DES is mentioned.
> > But advertizing nonsense is very common, and maybe this product is good
> > nevertheless.
> No, see the snake-oil FAQ. If you can't assume that a cryptographic
> software is fully trustworthy in any aspect, it should be considered
> useless.
I disagree. The advertizing is nonsense, accepted. And this does not
improve my trust into this company. But you're claiming, that the
encryption can be trivially broken, so please offer proofs for that
claim.
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Swapping can occur at every moment
No.
Page swapping is implemented by an LRU or derived algorithms. A used page
will not be swapped out randomly.
> And, of course, this is an issue. You can trivially mark small regions of
> memory as non-swappable.
Here you're right. But it is not significant.
> The Triple-Blowfish is what the implementation offers, thus the claim
> actually holds: There is a 1344 bit cipher-cascade in the product.
There is no claim "There is a 1344 bit cipher-cascade in the product."
or I didn't find it.
> > And: more than 256bit with a secure block cypher is nonsense, too.
> Well, that's clear.
OK.
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
<https://events.congress.ccc.de/congress/2006/Fahrplan/events/1422.en.html>
Sebastian Gottschalk wrote:
> Volker Birk wrote:
>
>> Sebastian Gottschalk <seppi@seppig.de> wrote:
>>> Notan wrote:
>>>>> Brute-forcing the key by
>>>>> attacking the key-generation scheme or some other flaw in the
>>>>> implementation has usually been very successful against this crappy
>>>>> software.
>>>> Cites?
>>> Is your Google broken?
>> Mine seems to be b0rken, too.
>>
>> DriveCrypt and TrueCrypt both are derivates of E4M. What is your problem
>> with DriveCrypt?
>
> The implementation of the key generation and key management. We've seen the
> plain keys being dumped to the swap file, we've seen the entropy collection
> reducing itself to about 40 bits of entropy...
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Volker Birk wrote:
>
> > Sebastian Gottschalk <seppi@seppig.de> wrote:
> >> Just encrypt something with DriveCrypt and run a program with high memory
> >> consumption in parallel. Most likely, the plain encryption key will end up
> >> in your swap file.
> >
> > Nice. But not significant, because no-one will handle this like that.
>
> Not significant? Swapping can occur at every moment, this setup just makes
> it more likely to demonstrate this issue.
>
> And, of course, this is an issue. You can trivially mark small regions of
> memory as non-swappable. This is a prerequisite for about any key handling
> in any crypto product.
So your all-so-clever crypto product marks some of its memory as
non-swappable and I hit the hibernate button? What then?
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Frank Slootweg wrote:
>
> > Sebastian Gottschalk <seppi@seppig.de> wrote:
> >> Volker Birk wrote:
> >>
> >>> Sebastian Gottschalk <seppi@seppig.de> wrote:
> >>>> Just encrypt something with DriveCrypt and run a program with high memory
> >>>> consumption in parallel. Most likely, the plain encryption key will end up
> >>>> in your swap file.
> >>>
> >>> Nice. But not significant, because no-one will handle this like that.
> >>
> >> Not significant? Swapping can occur at every moment, this setup just makes
> >> it more likely to demonstrate this issue.
> >>
> >> And, of course, this is an issue. You can trivially mark small regions of
> >> memory as non-swappable. This is a prerequisite for about any key handling
> >> in any crypto product.
> >
> > So your all-so-clever crypto product marks some of its memory as
> > non-swappable and I hit the hibernate button? What then?
>
> Then it's intentionally fucked up by the user, especially since he didn't
> RTFM. Unlike swapping, hibernate is trivially avoidable.
Ah! Another PEBKAC (non-)argument?
And *which* FM might that be? The FM which says how to disable
hibernation? *Why* would the user (want to) read *that*?
Anyway, a product like DCPP is surely also, and probably mainly,
targeted for the laptop market, which is very likely to use the
hibernation feature. So blaming the user for using an essential feature
is rather silly.
For the swap case the PEBKAC, because the user allowed physical access
or/and Administrator rights, but you don't say "PEBKAC", but instead
blame the DCPP supplier.
But for the hibernate case, you *do* say the PEBKAC. Why? Because you
can't see a way to blame the DCPP supplier? Other?
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Frank Slootweg wrote:
>
> > And *which* FM might that be? The FM which says how to disable
> > hibernation?
>
> F.e. TrueCrypt and PGP.
>
> > *Why* would the user (want to) read *that*?
>
> Because you simply can't use a highly complex program without at least
> knowing the basics? Sorry, but if the users lacks intent to read the FM,
> this is clearly his fault. As he deserves the resulting problems.
Yes, we are all quite well aware of your unrealistic expectations of
and opinions on users of commercial software.
> > Anyway, a product like DCPP is surely also, and probably mainly,
> > targeted for the laptop market, which is very likely to use the
> > hibernation feature. So blaming the user for using an essential feature
> > is rather silly.
>
> And now you're even talking nonsense. If the user doesn't intentionally
> goes to hibernate at the key creation *before* the hard drive gets
> initially encrypted, it's clearly his fault. After encryption, the
> hibernate file is placed inside the crypto container.
And the swap file *isn't* placed inside the crypto container?
> > For the swap case the PEBKAC, because the user allowed physical access
> > or/and Administrator rights,
>
> Even more bullshit. Swapping is done by the operating system as part of the
> normal modus operandi, and intentionally invoking is was just for the
> purpose of demonstration.
You missed the point. I'm not talking about your demonstration of the
exploit, but about the fact that a culprit has physical or programmatic
it access to the swap file, yet you don't blame the user for that.
> > but you don't say "PEBKAC", but instead blame the DCPP supplier.
>
> Of course, because it's something that's normally avoided by technical
> measures. And because it's not done by the user, but by the operating
> system following normal operation.
>
> And well, every competent cryptographic software programmer knows that, yet
> this super-big company fails to get even this simple thing right.
>
> > But for the hibernate case, you *do* say the PEBKAC. Why? Because you
> > can't see a way to blame the DCPP supplier? Other?
>
> I should blame you for wasting my time discussing with someone who doesn't
> even have a fu^W clue about the technological aspect he's discussing.
Yes, we are all aware of your superiority complex. It's becoming
rather a drag that you are always blaming others, but silently snip or
remain silent when people point out your misconceptions.
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Frank Slootweg wrote:
>
> >> Because you simply can't use a highly complex program without at least
> >> knowing the basics? Sorry, but if the users lacks intent to read the FM,
> >> this is clearly his fault. As he deserves the resulting problems.
> >
> > Yes, we are all quite well aware of your unrealistic expectations of
> > and opinions on users of commercial software.
>
> This is an expectation on sanity, not on users.
But the 'sanity' of users. My point is that the expectation is
unrealistic, so it's kind of an insane expectation of "sanity"! :-)
> >> And now you're even talking nonsense. If the user doesn't intentionally
> >> goes to hibernate at the key creation *before* the hard drive gets
> >> initially encrypted, it's clearly his fault. After encryption, the
> >> hibernate file is placed inside the crypto container.
> >
> > And the swap file *isn't* placed inside the crypto container?
>
> Might be, but this might already have been too late.
But the same goes for the hibernate file. So you do expect the user to
wait pressing hibernate until the hibernate file is placed inside the
crypto container, but it's apparently fine if he doesn't wait (i.e.
leave the system physically unprotected or/and open to exploitation of
Administrator rights) until the swap file is placed inside the crypto
container. Don't you realize the inconsistency in such reasoning?
> BTW, you came up with that.
Huh? I came up with what?
> > You missed the point. I'm not talking about your demonstration of the
> > exploit, but about the fact that a culprit has physical or programmatic
> > it access to the swap file, yet you don't blame the user for that.
>
> Physical access. Well, that's exactly what we want to protect against with
> implementing this crypto.
So you do agree that the user is as much to blame for leaving the
system open to 'your' swap file exploit as he is for leaving it open to
'my' hibernate exploit? I.e. he either is to blame in *both* cases or in
*neither* case. That's all I'm pointing out.
> >>> And the swap file *isn't* placed inside the crypto container?
> >>
> >> Might be, but this might already have been too late.
> >
> > But the same goes for the hibernate file. So you do expect the user to
> > wait pressing hibernate until the hibernate file is placed inside the
> > crypto container, but it's apparently fine if he doesn't wait (i.e.
> > leave the system physically unprotected or/and open to exploitation of
> > Administrator rights) until the swap file is placed inside the crypto
> > container. Don't you realize the inconsistency in such reasoning?
>
> No, since it's not under the user's control when memory pages are swapped
> or not. And, of course, because it's trivially avoidable by the software.
*My* point is, as I said, that for 'your' exploit to work, the
"culprit has [to have] physical or programmatic it [sic, sorry for that
typo, delete "it"] access to the swap file, yet you don't blame the user
for that.".
So you blame him for pressing the hibernate button, but not for
leaving his system open. Call me silly, but I call that inconsistent.
> And it's written in the manual that you should not press hibernate until
> the process is finished.
In the *DCPP* manual? This is the first time you say/imply that!
Before you referred to the manuals of *other* products (TrueCrypt and
PGP) when I asked about which FM the user was supposed to R and why.
(And I said "*Why* would the user (want to) read *that*?", i.e. why
would he read the manuals of *other* products when using DCPP?)
> *Geez*, what do you want more?
Some consistency in your arguments?
> >> BTW, you came up with that.
> >
> > Huh? I came up with what?
>
> You came up with the question how one could address the issue after the
> encryption has taken place.
I did no such thing. But let's drop this.
> However, the discussion was about the time
> before that happens, thus if there still is an unencrypted place where the
> key from memory could end up.
>
> >>> You missed the point. I'm not talking about your demonstration of the
> >>> exploit, but about the fact that a culprit has physical or programmatic
> >>> it access to the swap file, yet you don't blame the user for that.
> >>
> >> Physical access. Well, that's exactly what we want to protect against with
> >> implementing this crypto.
> >
> > So you do agree that the user is as much to blame for leaving the
> > system open to 'your' swap file exploit as he is for leaving it open to
> > 'my' hibernate exploit?
>
> No. The user generally can't avoid the memory swapping issue, even if he
> wanted to. Your "hibernate" exploits involves the user doing something
> intentionally wrong beside the given warnings.
See above. It's only "something intentionally wrong" if it's
specifically stated in the (relevant (installation?) part of the) *DCPP*
manual. If you say *that* is indeed the case, then I concede your point
and would appreciate a verifiable (web) reference.
"Peter" <hello@hello.hello> wrote in
news:45b7acff$0$727$5fc3050@dreader2.news.tiscali. nl:
> Hello,
>
> I have two questetions about DriveCrypt Power Pack. I have encrypted
> my system partition (C) and my data partition (D) and my external
> harddisk (E), which I use for making backups.
So.....what's the reason for encrypting ALL of this ?
DCPP 
Linear Mode
