Subj : Reg methods
To   : Scott Adams
From : Eddy L O Jansson
Date : Thu Sep 20 2001 11:24 am

 Who is it that you want to protect your software against?

SA>      Disadvantage: Usually takes up alot of space and expense       
SA> sending out the files (if by mail-disk).

 Pros: You can personalize each copy and tag them as to track any
 "leaks". Simple example: Req. a credit-card to register. Take the
 number, hash (md5/sha) it together with a secret password and
 distribute the hash around the executable. I would advise against
 spreading the actual card#.

 Distribute on-line and you don't have to worry about expense.

SA> (#3 or 4 I think).  Nothing to this day could break      it or crack
SA> it.  It could not even be copied.  You could not      even get a

 Yeah, right.

SA>    Those are the main methods I know of.  There are probably others

 How about "don't use one"?

SA> using CRC values, dates and secret random codes.  Then more that

 Don't bother with CRCs. They should only be used to detect bit-errors or
 possibly other non-cryptographic uses.

SA> used all of the above plus 30-50 other steps.

 .. and then it all came down to a single boolean check. How tragic.

SA>    So does anyone know of a general scheme that seems to work   
SA> most often that you don't see crackers for?

 If you use registration-keys, make them sparse. Download the Nero
 keymaker with source and read the included documentation for an
 example. (The idea is to _not_ use all keybits in all versions)

 The only really effective protection is a client<->server authentication
 scheme, where you control the server.

 /%/)+Eddy

---
 * Origin:  (2:203/233)

.