shareware/demoware

[Dar Scott]

On Friday, June 14, 2002, at 12:02 PM, Ken Ray wrote:

> One thing I've always thought about is using a foreign constant in the
> algorithm. Something like an reversal of an animal's name (like 
> "noil" for
> "lion") that has nothing to do with the company or product would 
> be fed into
> the algorithm. It's not something that is likely to be guessed, 
> and it would
> be necessary to know in order to hack the algorithm.

The lion is a good idea, but I think thinking in terms of "hack the 
algorithm" is the wrong way to go.

In a key generator and product pair as we are talking about there 
are couple features that are crucial.  (Other features are needed 
to make things work, of course.)

The features:

1.  The key generator and the specific product line share a secret.

2.  It is hard for others to bypass or figure out the secret.

(This is not strictly true, it is possible to have a key generator 
_maker_ that knows the secret, but the key generator does not in a 
rough sense, but that is beyond the scope of what we are talking 
about.)

If the method used is obfuscation, the scrambling and unscrambling 
of data, the methods for those embody the shared secret.  These are 
very easy to figure out and there is a tendency to come down hard 
on these methods, but I think the token level of protection is 
appropriate in some cases.

Though this is very weak, my main complaint is that they are a lot 
of work.

If you want your key to look pretty or to look secure or to be easy 
to enter, then do all you need in order for your product to look 
good.  But my advice is to not bother with scrambling beyond what 
that requires, there are better and easier methods.

Suppose you encode the expiration date, license level and license 
number in the first several digits of the key and that the encoding 
is so thin that one can read them without thinking after learning 
the encoding.  Who cares?  This is probably stuff the buyer would 
want to be able to read.

Now back to the lion.  Suppose we all find a good method.  Suppose 
the shared secret is some string (given the method itself is not 
secret).  One might try to hack a program by opening the app in a 
text editor and looking for some string like "Here is the shared 
secret for unlocking my precious Balderdash 2200 Pro!!".  Adding a 
lion would allow one to use the proven key scripts yet make a 
change.  One possibility would be to have a lion that obfuscates 
the string in the file.  Remember, the shared secret is in your 
program and it is only a matter of time should someone really want 
to dig it out.  The lion only slows people down.

In a sense, the lion is a per-maker secret as part of the 
per-product secret.

(These comments may not apply to other ways to protect one's 
product.  This is not my area of expertise.  Use only under 
supervision.  etc.  etc.)

Dar Scott