[R] Sourcing encrypted files

[Marc Schwartz]

On Tue, 2007-09-18 at 07:47 +0100, Prof Brian Ripley wrote:
> On Mon, 17 Sep 2007, 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?
> 
> That's not what I understand by 'to pipe'.  You could use a pipe() 
> connection with source() if you had a pipeline decrypter, either
> 
> decrypt filename | Rscript
> 
> or
> 
> source(pipe("decrypt filename"))
> 
> Those would be slightly safer as the decrypted source code is (probably) 
> never written to the file system.
> 
> I am not sure what you are trying to achieve: since the R code is going to 
> be decrypted it will be possible (and I suspect easy) to get hold of the 
> decrypted version.  (Consider for example running a modified version of 
> source() that dumped out the parse tree.)  Using a package to read the 
> encrypted file and feed the decrypted source to the parser at C level an 
> expression at a time would make this harder to circumvent.
> 
> (Unlike Marc Schwartz, I am presuming the aim is to protect scripts from 
> casual inspection on someone else's machine: as Marc says there are better 
> ways to protect code and data on your own systems.)

I had not considered the scenario of running the scripts on someone
else's machine and protecting what may be a 'proprietary' script.

The same issues I noted apply here and you would need to consider the
risk of disclosure against the costs/complexity to protect it. 

As Prof. Ripley has noted, there are other file based approaches, but
you would need to consider the risk that the script would be written to
the local disk in the clear, either during processing to a temp file or
perhaps during memory paging.

Then the issue becomes the level of sophistication of the owner of the
computer upon which you are running the script and their motivation to
try to locate/read the clear text version.

If this is the scenario of concern, one additional approach, that would
at least eliminate the need to actually copy the script to the local HD,
would be to store the script on removable media, such as a USB flash
drive and source/run it from there.  This does not eliminate the
possibility that the file could be copied to the local HD as a temp file
or during memory paging, but at least it reduces the risks to some
extent.

The ideal option of course is to only use your own hardware and control
access to it.

HTH,

Marc Schwartz