[Back to DATATYPE SWAG index] [Back to Main SWAG index] [Original]

    {
    > I'm trying to come up with a registration keying routine for my
    > software, but am at kind of a loss on how to do it and make it somewhat
    > secure or a pain to crack.
    > Here's a program that supposedly uses RSA encryption, but it must be for
    > an older pascal because I couldn't get it to compile with version 7.0
    > since it tries to use a declaration of Integer[36]. I tried it with
    > just a regular Integer declaration and I couldn't get it to work (I
    > think).

     OKay...  As I recall, that Integer[36] thingy was implemented on DEC
     VMS systems (possibly others) as kind of a work around for, faster than
     real, large (greater than maxint) integer math applications.  You might
     try declaring the variables as longint to test out the algorithm..
     It's 32 bit, but then it may be a hair too small even for the math
     tricks that your rsa is doing...  Making such large numbers that it
     needs 36 bit integers to avoid overflows..

       Anyway.  I was really wondering why you didn't want to implement an
     XOR type of encryption method..  It's really so much faster than any
     math trick type of implementation...As there is really no math
     involved..

     Encryption security has three basic concerns:

     It has to be secure when the enemy knows or has in possesion the method
     that you encrypted your target,
     It has to be secure when the enemy has in his possesion, your target,
     And it has to be secure if the enemy has in possesion, your method,
     your target and your key.

     Whatever the method you use, all you are really doing is changing the
     value of a byte (the simplest item) to some other value.  Or you are
     restructuring the method of access.

       Or in plain english, you compress your file, then mess it up with
     some encryption algorithm that uses a key to decrypt it.
     How you compress, and how you encrypt doesn't really matter.

       What matters, is the possible number of ways that you COULD have
     used.  If that number (of ways) is computable, then your encryption
     method is crackable.

       This number (of possible methods) is called the domain of solutions.
     If the domain of solutions can be written into a program then any
     method and combinations of methods is crackable.

       To be uncrackable, the domain of solutions must be uncomputable.
     Actually, it may very well BE crackable, but so long as it is
     uncomputable, the cracker has no way to determine where to begin
     cracking!  Thus the defence or security lies not in remaining
     uncrackable, but in remaining encrypted.  Making it take too long to
     crack.  In other words just how much time will it take to solve the
     puzzle and for how long does the puzzle have to remain unsolved before
     it is no longer relevant.

       The perfect encryption engine, would be something that has too vast
     of a number of methods to be computable, yet very simple to operate and
     use.  The answer to this seemingly paradoxical question is simple.  You
     have to introduce a non machine element into the engine.  The human
     element.  A human determined key sequence.  In other words, your key is
     defined not by position or elements, but in steps.  Or instructions on
     what to do that is not machine or engine readable.  Or in other words,
     it can't be automatic (one step) and secure.

     There are many methods, including weird math methods.  However, it has
     been shown that ALL weird math methods are no more secure than simply
     adding 1 to the value of any byte.  The proof of this was published in
     a mathamatical journal some years ago, sorry, I don't remember what it
     was..  But it basicly stated that any weird math method could be broken
     by a simple brute force program that shifted the values of varying
     lengths of bits of a small portion of the target until it found
     recognizable text or data.

     Practical concerns:
       You want a Keyed registration system.  You want to be able to send
     the registered user a post card with some instructions on it on how to
     make his program registered.  This instruction card must be unique to
     his copy of the program.  I assume that the unregistered version of the
     program will be massively distributed I.E. Shareware concept.  Simple.
     You have two maybe three steps involved.
     1 :  A uniqueness must be made in the program, something that
     identifies and connects that particular copy of the program to that
     particular registered user.  A name...
     2:  You need some method of securing the program to that particular
     registered user.  A number or code that interacts with the name to
     produce a file, or key that must then be present during operation for
     the program to work in the registered mode.
     3:  The program must be made aware that it has been registered and if
     the registration code is found to be missing, it will revert to an
     unregistered mode.

        What may happen: If the name and code is given out or stolen,
     it must not work with any other copy of the software.   This is the
     most difficult effect to produce and is not possible to implement
     without your direct involvement in the proccess.  Don't expect to be
     able to produce this effect without direct involvment.   In effect, you
     have to make a unique modification to the program unknown to the user.

     I once worked on a project that had to be totally secured in this
     manner.  The software had to be registered not only to a specific
     individual or company, but also had to be registered to a single
     machine.  We had to be absolutely sure that there were not multiple
     copies of the software executing on different machines, or indeed on
     the same machine or that there were multiple copies of the software
     that could be installed/deinstalled on the same machine.  It was a
     financial system and the possibility of using it to produce multiple
     books existed which we had to avoid at all costs.  It took a while but
     we solved the problem, unfortunately the software was never produced or
     used, as the company I created this system for went belly up before the
     project was installed and the project was cancelled.

       What we used was a regestration key file, that was modified by the
     software, so that it couldn't be used again, it couldn't be used by any
     other copy of the program.  However, if something adverse happened, the
     program knew that it was modified and the same copy of the software
     (that had been origionally registered) could use the key again.  Also,
     the key was time stamped, it was only good for a certain range of
     dates, it couldn't be used to register a copy of the program outside a
     3 day limit.   Also, the software wouldn't operate, even if it was
     registered, if it detected that the date was 30 days since it last
     operated.  It had to be in continuous use at least every 29 days for it
     to remain registered.  Remember that this was a financial package, and
     it had to remain updated to be relevant.  We also had planned to link
     to and download it's data every 30 days and provide a new key to
     operate for the next  30 days.  Thus if the software was installed, and
     the phone lines went down, or we went out of business, the software
     would refuse to operate ( in fact it would self destruct and encrypt
     all work in progress) after 30 days of no contact with home office.
     Also note that at no time did the end user ever have the key file
     before the program saw it first and got a chance to modify it.  Once
     that happened, it couldn't be used by some other copy.  Also, we
     planned on not telling the end users that the software would only work
     on one machine ( the machine it was installed on) We wanted them to
     attempt to pirate the software..
     Why?
       So that we could test their honesty as partners in the business...

       I suppose that this was somewhat mercenary on our part, but then, I
     didn't make those kinds of decisions, I just wrote the software....
    }

[Back to DATATYPE SWAG index] [Back to Main SWAG index] [Original]