Messages in this thread | | | Date | Thu, 14 Apr 2005 21:27:22 +0200 | From | Stefan Seyfried <> | Subject | Re: [PATCH encrypted swsusp 1/3] core functionality |
| |
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/
| |