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
Dennis Fisher MD
P < (The "P Less Than" Company)
Phone: 1-866-PLessThan (1-866-753-7784)
Fax: 1-415-564-2220
www.PLessThan.com
[[alternative HTML version deleted]]
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 > > DennisI 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
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.)> Of note, the scripts are not terribly long - 50-200 lines each. > > Thanks > > Dennis > > Dennis Fisher MD > P < (The "P Less Than" Company) > Phone: 1-866-PLessThan (1-866-753-7784) > Fax: 1-415-564-2220 > www.PLessThan.com > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Dear Dennis, Ignoring the reasons why you might want to do this, you may want to explore a ram disk. I don't know which OS you are using, but assume a unix or unix-like OS, there may be a straightforward way to mount a ram-based volatile disk and decrypt your file to there. Another option would be to use an encrypted partition. Best wishes, Mark On 17/09/2007, Dennis Fisher <fisher at plessthan.com> 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 > > Dennis Fisher MD > P < (The "P Less Than" Company) > Phone: 1-866-PLessThan (1-866-753-7784) > Fax: 1-415-564-2220 > www.PLessThan.com > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ >-- Dr. Mark Wardle Specialist registrar, Neurology Cardiff, UK