[R] Sourcing encrypted files

[Marc Schwartz]

On Mon, 2007-09-17 at 15:56 -0700, Dennis Fisher wrote:
> Colleagues,
> 
> I have an unusual problem; I am wondering whether anyone has dealt  
> with it and found a solution.
> 
> I have a script that needs to be encrypted.  R will then be run on  
> the script.  There are various means to decrypt the file, some of  
> which leave the decrypted code on the hard drive for an excessive  
> period.
> 
> One means that I have considered to deal with this is the following  
> (the unix code is not correct, just sufficient to communicate the idea):
> 	system("decrypt ...")
> 	system("rm encrypted file")
> 	source(decrypted file)
> 	system("rm decrypted file")
> 
> Another approach would be to pipe the decrypted version to R in the  
> command line (as it is being decrypted).  Obviously, this could be  
> done with R < decryptedFile but this leaves the decrypted code  
> exposed.  Is there some other means to accomplish my goals using  
> something on the command line?
> 
> Of note, the scripts are not terribly long - 50-200 lines each.
> 
> Thanks
> 
> Dennis

I am curious as to why the script needs to be encrypted versus needing
to encrypt/protect the data that the script would presumably act upon.

Are you concerned about somebody gaining read access to your HD?  Keep
in mind that simply deleting a file only modifies file system entries.
It does not actually delete or wipe the physical data that the file
contained and folks with modest means can recover the clear text version
of the file.

We are not talking about needing TLA's (Three Lettered Agencies) to do
this.

If you are using a journaling file system such as ext3, the process of
even securely wiping individual files becomes even more complicated.

The best approach however is to take a holistic view on the process.

Don't just encrypt the source file, but encrypt entire partitions. For
example:

  /home
  /tmp
  swap

using one of the various means to do so such that files will be
encrypted/decrypted transparently during disk I/O.  Files in these
partitions are stored in encrypted format on the HD and only decrypted
when read.

This can be done via dm-crypt/LUKS, loop-aes, TrueCrypt and other
similar utilities. 

Encrypting /home means that everything in your userspace partition is
encrypted.

Encrypting /tmp and swap means that temporary files and anything moved
from RAM to HD during memory paging will similarly be encrypted.

The HD I/O overhead on a reasonable system is modest. In my case, only
about 15%. The CPU overhead is negligible.

I use dm-crypt/LUKS with 256 bit AES on my system running F7. Since I
deal with clinical data and am subject to HIPAA issues this is the best
approach for me and protects my laptop from inappropriate disclosure.
When my system boots, I am prompted for a lengthy passphrase to 'unlock'
the encrypted partitions for subsequent mounting and use. This occurs
before even logging in.

When done with my system, I shut it down. I never use hibernation/sleep
modes.

I also have the same approach for an external HD that I use for daily
backups and create GPG encrypted tarballs for monthly backup to DVD for
secure longer term storage.

HTH,

Marc Schwartz