Re: [PATCH encrypted swsusp 1/3] core functionality

[Stefan Seyfried <seife@suse.de>]

Matt Mackall wrote:

> Any sensible solution here is going to require remembering passwords.
> And arguably anywhere the user needs encrypted suspend, they'll want
> encrypted swap as well.

But after entering the password and resuming, the encrypted swap is
accessible again and my ssh-key may be lying around in it, right?

So we would need to zero out the suspend image in swap to prevent the
retrieval of this data from the running machine (imagine a
remote-root-hole).

Zeroing out the suspend image means "write lots of megabytes to the
disk" which takes a lot of time.

The "encrypted suspend" case avoids this. It is absolutely useless for
the "machine is stolen while suspended" case, since the key for
decrypting the suspend image is stored in the suspend header (but
destroyed during resume).

We need both:
  - encrypted swap for the "stolen while suspended" case
  - encrypted suspend for "broken into after resume while still running"
    case.

i hope this helps...

Stefan
-- 
seife
                                 Never trust a computer you can't lift.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/