From: bbense+comp.lang.ruby.Apr.15.02@... Date: 2002-04-16T09:23:02+09:00 Subject: Re: crypting ruby source -----BEGIN PGP SIGNED MESSAGE----- In article <20020415125925.A90269@freeze.org>, Jim Freeze wrote: >On Mon, Apr 15, 2002 at 11:28:53PM +0900, Mark Probert wrote: >> >> At 02:20 PM 4/14/2002 +0900, Ed wrote: >> >Ludo wrote in message news:<3CB31298.13A44B26@enib.fr>... >> > > Hi, >> > > >> > > Is there anybody aware of a method to crypt the sources of ruby software >> > > please ? >> > >> >The reasons for doing this are obvious, $$. You want to distribute >> >your work without anyone learning your secrets. I think more folks >> >would use Ruby if it had this feature. >> >> There are other reasons as well. I want to be able to distribute >> data collection on customer sites. One of the requirements is that >> I be able to get into various boxes that require a fixed password. >> This based on the date of the box, and then apply the date to an >> algorithm to generate the password. And I don't want the customer to >> have that password algorithm ... >> =- Security through obscurity never works in the long run. If your algorithm can't be public, it can't be secure. > >I think this is a good idea for some situations, especially >as you mention above for storing data. >And, I can't imagine this being too terribly difficult to implement. =- It is extremely difficult to implement in any meaningful way. At best you get security through obscurity, which may be enough for some uses, but at best you are just fooling yourself. If this was easy to implement, record companies would be doing it today. > >If I was implementing this I would do it as follows: > 1. Write a controller in c. Granted, this is the weak part > of the system, but unless there is internal cooperation from the > ruby parser and encrypting of the AST's, then, as far as code > is concerned, the security if through obscurity. > > 2. Write a special require module (in c) that decrypts its source. > > 3. Use the c controller to load the encrypted ruby code, decrypt > the require'd modules and run as normal. > >Again, the reason for the c controller is so that it is not trivial >to insert a watch point to read the code after it is un-encrypted. =- This is trivial for any unix hacker to get around. Root can read the memory of any process and I only have to find a break point somewhere in the interpeter to stop the code while the strings are still in memory. > >Now, how does one get the encryption key to the controller program. >The nice part of ruby is that it would not be difficult to write a >challenge-response system as part of the controller so a customer >may gain access to their program and data. =- This system won't stop even the mildly dedicated, and it will piss off your customers. Managing keys in a secure fashion is much harder than you are making it out to be. If the key to decrypt the data is on the machine that runs the program, I can read the src. =- Booker C. Bense -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPLtrMgD83u1ILnWNAQHEbwQA1EBoO9f12OQLI9KD1NkLLhMp+Jod+bya lUkWlKSZ8ULbR8X7JlXDl21GEcNQoPOPWkQCRAv01GYxAVnnGEfzPsY8viSwiNpd gzU2paFv1m8Dz8KbpgfpLo8uLV/5MPlnPRdM9cANycKQNAB5dC0og4u6txSfwp5y h89Fjwe+S1g= =PSPM -----END PGP SIGNATURE----- --