Re: [Duplicity-talk] PASSPHRASE, the environment, memory, etc.

[Neal Clark]

-----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-12

so 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: SHA1
>
> I've noticed various "how can I hide my key" questions lately, and  
> it makes me
> ask 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 person
> with 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  
> only
> decrypt/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 been
> deleted 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 were
> > moved, the data isn't coming back without a geom metadata backup,  
> > kept
> > nicely tucked away.
> >
> > > By spreading sensitive knowledge across more systems (both the  
> > > machine
> > > being backed up and the separate machine which stores the key  
> > > used for
> > > encrypting 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 was
> > curious more about how the password 'hangs around' in the environment
> > and in duplicity itself. Like for example, could I automate a way to
> > fudge the environment duplicity executes in, like perhaps in the  
> > python
> > code, delete the environment variable after its been read into the
> > program? And also, is there anything I can do to 'secure' or what  
> > have
> > you 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-----