GC and security

[Les Schaffer]

Paul Rubin wrote:

> GC simply releases the memory for other uses in the application.  It
> doesn't necessarily zero the memory.  


release is followed by some probability of eventual overwrite; check.

> 
> Just what attack are you trying to protect against, if swap space is
> less of a problem than leaving keys around in ram?

keys are on a USB drive key ring. gpg accesses the key ring as needed,
but in a separate process. and gpg is done with its work early on in our
app lifetime. comes back at end to encrypt and then app is done.


> Keep in mind that the weakest part of this application is likely to be
> the passphrase itself.  Is there a way to get rid of it?

we got some suggestions from other parts of this thread. or do you mean
getting rid of the need for a passphrase? the passhprase protects the
private key on the USB drive.

> Is this data on a laptop?  Why do you want to do encryption in the
> application, instead of using an encrypted file system?  

i looked at EFS and TrueCrypt.

There was some questions (from MySQL pro) about how MySQL writes would
interact with EFS. also, EFS seems to store key pairs on disk, and the
passphrase was limited to the Windows user login password.

i remember looking at TrueCrypt and deciding against it. couldn't see
how to interact with it via python script. vaguely recall being
dissatisfied with keys and passphrase.

but the main reason? we were asked to encrypt the MySQL tables carrying
sensitive information.


> Is there some
> obstacle to using a token (like a smart card) to hold the key?

USB drive holds the GPG key. the drive must be inserted at start of
application, and must be pulled after authentication otherwise the app
warns and shuts down. The USB drive carries a digital signature, and
also encrypted identifying information for the user.

Les Schaffer