|
Posted by Frank Slootweg on January 26, 2007, 5:01 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> Frank Slootweg wrote:
[deleted]
> >>> 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.
| 
XML site map