On 07/27/2015 07:45 AM, Carlos E. R. wrote:
On 2015-07-27 05:05, Anton Aylward wrote:
On 07/26/2015 10:25 PM, Carlos E. R. wrote:
Well, yes, having .fetchmail on a encrypted partition is a second order pseudo-secret. When you are logged in and active that partition is "unlocked" so you can use it. Not exactly, because you need to enter a password to open the partition at some point.
Once again I refer you to the John Sandford novel. The laptop was stolen while the main user was logged in and had opened up the encrypted user partition.
Well, even if I got that novel, it would go to the end of my reading queue, so I would not read it till a month. You will have to explain how he does it.
Assume the laptop is running, with the encrypted spaces open, yes.
Yes, the real user is using it.
When a laptop is stolen it is normally suspended/hibernated, and inside a bag or on a table, while the owner is somewhere else. Meaning that the screen is locked, so the thieve can not access the running system.
Why are you making that assumption? In the novel, the real user was wheelchair bound. He was knocked unconscious (and killed) while using the machine. While you are I might walk away from the table to schmooze, lunch or micturate, he didn't have that option, so it seems he didn't have a screen saver. So long as the machine was powered up it was logged in and the encrypted partition was open. Now you or I might do things differently, but that's the novel.
UNLESS you have some kind of scripting that says 'open encrypted partition using keyword; extract passwords; close encrypted partition; forget keyword' then all is lost.
Actually that is what I intend to do. Have an encrypted file, prompt for a password, and create a clear text copy of the file in tmpfs, so that it is automatically lost on power down or reboot.
Personally I think that the idea of having a cleartext version available anywhere is a bad idea. If it matters that much there should be no cleartext version anywhere except in memory. And possibly not even that. The application should read the RC file and the RC file should have the password fields encrypted. The application should decode them in its internal memory, use them, and the ** overwrite that internal memory ** so that even memory scrapers will have a limited window of opportunity. Of course all this is really a pole of crap, isn't it? You're not using those IMAP/POP passwords anywhere else are you? You are reading (or at least rendering) the email as clear text. Its not that we couldn't have a email system that makes use of cryptographic signatures as ID, diffie-hellman exchange to generate unique, one time passwords of arbitrary bit length (you want 4096 bits, sure, no problem!). Such schemes have been proposed and even implemented. But WHY? The whole point of mass mail or mailing lists like this is that its in the KISS Class. You want secure point-to-point email between individuals or small groups? it comes down to key management. Yes do it over SMTP, its ubiquitous. Try PGP for starters. At least it keeps external keys encrypted. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org