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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
