Home
Up

Here's some more information and explanations.

I relied on a professional code of ethics to come to an embarrassing decision: it would not be appropriate to post software that makes it easy to read scripts that someone has tried to protect through encryption. Section 1.2 of the ACM code of ethics states "avoid harm to others."  At least one respondent to my original message provided evidence that readily available script "cracking" code would be harmful to him.  At the same time, such code evidently would be helpful to a number of people for recovering capabilities that they had inadvertently lost.  In the balance, the "avoid harm" imperative won out.

That original message was borne of frustration, because it appeared impossible to present a constructive solution to the problem of weak encryption for scripts.   However, stimulated by the ideas presented by the many respondents to that message, I have developed an approach that can help protect code.  (See the "Avenue Uglification" link at left.)  Once this procedure is made more automatic, either by myself or some enterprising Avenue programmer, developers will have greater protection against theft of ideas and code.

Rather than summarize all the points made--an exercise that would indubitably be one-sided--I have tried to make it easy for you to explore the many ideas contributed by the ArcView developer community.  The following outline provides direct links to copies of the original messages.  Those messages are, to a degree, linked into threads among themselves so you can chase down references among them.  If you want, you may proceed directly to the messages.  They appear in order my e-mail software saved them, which is roughly chronological.

These pages reflect messages received through 2 August 1999.  Since then, I have had several productive interchanges with one of the respondents who brought this issue to the attention of ArcView developers and subsequently with one of those developers.  I still have no evidence of a commitment from ESRI to improve script encryption substantially, however.

My requirements for a well encrypted script are simple and readily tested:

1. Encryption must be irreversible: useful information present in comments, indentation, and other lexical elements of a script should disappear altogether.
2. Encrypted scripts should appear to be random sequences of characters.   The sense of "random" is subtle here.  The characters ESRI can use for script encryption are limited, because encrypted scripts are stored in ODB files, which are in ASCII format.  By random, therefore, I mean that the distribution of characters that actually appear within an encrypted script is random.  The sense in which I mean "random" is strong: not only should those characters have statistically equal frequencies, they must also exhibit no apparent correlation or other patterns as tested by standard random number generation tests.
3. Encrypted script text should be well mixed: it must not have a strongly local association with the original plaintext.  What this means is that if you add or remove a character from a script, or change a single character, the resulting encrypted script changes radically, apparently at random, throughout a long sequence of its characters.

You might wonder whether this is possible.  Yes, indeed, it is.  My Avenue uglification program achieves the first criterion.  The second is readily achieved by XORing plaintext with a practically infinite sequence of pseudorandom numbers, such as those produced by a good random number generator (which Avenue has, provided it is appropriately used).  The third can be achieved by applying a sequence of long-range permutations (which may be predefined or generated on-the-fly by a random number generator) to the uglified script before further processing.  After all these procedures: uglification, XORing, and mixing, just about any cipher method--including the one currently used by ESRI--will then do the job adequately.  A strong cipher method, like DES, would do the job even better.

ColorRamp, Memorized Calculations, Rotate, Sample, and Tissot  are  trademarks of Quantitative Decisions.  All other products mentioned are registered trademarks or trademarks of their respective companies.

Questions or problems regarding this web site should be directed to webmaster@quantdec.com.
Copyright © 2000-2001 Quantitative Decisions.  All rights reserved.
Last modified: Friday August 31, 2001.