DCPP

DCPP
Secure Home | Search | About
Login Password
Register Now! Lost Password?
 General Computer Security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content add this group's latest topics to your Google content
Subject Author Date
DCPP Peter 01-24-2007
---> Re: DCPP Sebastian Gotts...01-24-2007
| | ---> Re: DCPP Sebastian Gotts...01-24-2007
| | `--> Re: DCPP Volker Birk01-25-2007
| ---> Re: DCPP Sebastian Gotts...01-25-2007
| | |--> Re: DCPP Volker Birk01-25-2007
| |--> Re: DCPP Volker Birk01-25-2007
| ---> Re: DCPP Sebastian Gotts...01-25-2007
| | ---> Re: DCPP Volker Birk01-25-2007
| | ---> Re: DCPP Sebastian Gotts...01-25-2007
| | ---> Re: DCPP Volker Birk01-25-2007
| | | `--> Re: DCPP Sebastian Gotts...01-25-2007
| | `--> Re: DCPP Frank Slootweg01-25-2007
| ---> Re: DCPP Sebastian Gotts...01-26-2007
| ---> Re: DCPP Frank Slootweg01-26-2007
| ---> Re: DCPP Sebastian Gotts...01-26-2007
| ---> Re: DCPP Frank Slootweg01-26-2007
| ---> Re: DCPP Sebastian Gotts...01-26-2007
| ---> Re: DCPP Frank Slootweg01-26-2007
| ---> Re: DCPP Sebastian Gotts...01-26-2007
| `--> Re: DCPP Frank Slootweg01-26-2007
|--> Re: DCPP Volker Birk01-25-2007
Posted by Sebastian Gottschalk on January 25, 2007, 10:54 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Volker Birk 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.

You may understand that any modern OS even swaps out used pages if it
decided that the memory might me much more useful for some other purpose
(f.e. file system cache). Not just that, Windows usually runs working set
trimming from time to time.

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

The claim is that a 1344 bit cipher or cipher-cascade is implemented by the
product.

Posted by Frank Slootweg on January 25, 2007, 5:14 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
> Volker Birk 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?

[deleted]

Posted by Sebastian Gottschalk on January 26, 2007, 6:18 am
If you were  Registered and logged in, you could reply and use other advanced thread options
Frank Slootweg wrote:

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

Posted by Frank Slootweg on January 26, 2007, 10:11 am
If you were  Registered and logged in, you could reply and use other advanced thread options
> Frank Slootweg wrote:
>
> >> Volker Birk 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?

Posted by Sebastian Gottschalk on January 26, 2007, 10:54 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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.

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

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

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

Similar ThreadsPosted
DCPP user password?! September 16, 2007, 1:37 pm

The site map in XML format XML site map

Contact Us | Privacy Policy