|
From: | Neal Clark |
Subject: | Re: [Duplicity-talk] PASSPHRASE, the environment, memory, etc. |
Date: | Thu, 12 Apr 2007 20:46:24 -0700 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jay,That is exactly what i would want to do, but I'm not sure how to do it. I've only played around with duplicity for a few days, and my experience with pgp doesn't go any further than sending encrypted e- mails, basically. How can I do that given the syntax of duplicity? Cause when I run like.. --list-keys vs. --list-secret-keys, I get the same key id for my public/private key:
pub 1024D/22D10EAD 2007-04-12 sub 4096g/16D24883 2007-04-12 sec 1024D/22D10EAD 2007-04-12 ssb 4096g/16D24883 2007-04-12so I'm not sure how I could specify the --encrypt option to say "use the public key and not the private key and don't ask me for a password." Do I do something on the gpg end, changing the public key's ID somehow or something to that effect (c/f above, only experienced with encrypting e-mails :)
- -Neal - -- public key: http://thrownproject.com/8C02CC33.asc On Apr 12, 2007, at 7:02 PM, Jay Summet wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1I've noticed various "how can I hide my key" questions lately, and it makes meask the following question:Why not have duplicity use gpg to encrypted data with a public key (to a private key) so that you can encrypt data with only the public key, and only the personwith the private key can decrypt/restore the data?Obviously, some indexing data would have to remain unencrypted (or encrypted with a symmetric cypher and a locally stored password), but wouldn't such a scheme allow you to encrypt/backup on an "untrusted" box, and then onlydecrypt/restore with a remotely stored secret (private) key?(Although really, if they have full access to the box you are backing up, the only benefit of having encrypted backups is to protect data that has beendeleted already...) Jay Neal Clark wrote:On Apr 12, 2007, at 4:25 PM, Charles Duffy wrote:Fishing a passphrase out of an environment variable on Linux is dirt simple -- it exists in cleartext as /proc/<pid>/environ. You don't want to use /tmp either; /dev/shm would be slightly better, but not much at all.Thanks, never knew that. Do you know how this works on FreeBSD (w/o procfs)?Frankly, protecting a system from an attacker with full hardware access is a losing game -- but I'd think you'd want to keep the password on the system being backed up, rather than anywhere else. After all, you keep the data itself there; if it's not secure enough to store your key, it's not secure enough to store the data either, and you should move.Well, its not that its not secure enough. They can't login to the machine, obviously, and all the sensitive data is on a geli encrypted partition, so if the machine were powered off or the hard drive weremoved, the data isn't coming back without a geom metadata backup, keptnicely tucked away.By spreading sensitive knowledge across more systems (both the machine being backed up and the separate machine which stores the key used forencrypting the backups), you're increasing your overall exposure as well as adding more moving parts (and thus failure cases).I guess I could just keep the passphrase on the encrypted disk to solve (or at least in some way address) the physical access vector, but I wascurious more about how the password 'hangs around' in the environment and in duplicity itself. Like for example, could I automate a way tofudge the environment duplicity executes in, like perhaps in the pythoncode, delete the environment variable after its been read into theprogram? And also, is there anything I can do to 'secure' or what haveyou the fact that the passphrase is in memory? Thanks for the reply :) Neal -- public key: http://thrownproject.com/8C02CC33.asc_______________________________________________ Duplicity-talk mailing list address@hidden http://lists.nongnu.org/mailman/listinfo/duplicity-talk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUBRh7kqLWkkhmZq4xxAQJ9OAQAkz7iJxMSrHi+6gU7E0Ll0VfIIjtVQPzW iZyG0rJ0YKNxWRwwYI8GRUkIDnvZJqTO5vqZLV0YnqbdyX6FeHZsBUhEOziuRstW G54IpjPcEdbKQ7PAN86f5pNpM7sYlAc/fKvs09UB2Qimt5AtRg6BNqraxIInzfoa +emMBg+Fw5I= =qbLe -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGHv0ROUuHw4wCzDMRAqQRAJ9FJ2V8RDi3znKi+Vfj4BvpDZNakQCgkCIH LER2ALY2LAXSX581ixUxurY= =8qVj -----END PGP SIGNATURE-----
[Prev in Thread] | Current Thread | [Next in Thread] |