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

[Jay Summet]

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