hi guys

I have been reading some anti crack texts, and one of the things I read was that you should never include the decrypt algorithm in the program or making a keygenerator would be "easy". Why not? my registration scheme is something like this and don't see any obvious fault.

I generate on my pc
encrypt(username, key) => scrambled

on end-pc
registered = decrypt(scrambled, key) == username



To make a key generator I think the username should be part of what's processed on the end-pc, like

encrypt(username, key) => scrambled
registered = encrypt(username, key) == scrambled

but such a registration scheme doesn't make much sense to me.

well please enlighten me

Hi there:

Well, the answer to your question is and cannot be direct. For years, s/w authors have been doing what you're saying... Okey, let's get to some details....

Typically, users must register the program, so you need two values (A) a name or something (B) a function that generates a deterministic value out of this. This is your registration function, right?

So,

Keycode = RegFn(name) /* substitute name with anything */

To do verification, you need the inverse of this function

purported name = RegFn-1(KeyCode) /* treat -1 as inverse */

Now, this is what is shipped with the software right?

As a cracker, it is fairly *easy* to step through your code/do a dead-listing and obtain the algorithm for Part 2. So given a keycode what it decrypts to and there by compute part 1 (the keygen). Hope I'm making sense....

Now, s/w authors are fast learning all the tricks and do not do key checks in one place. Now there are tricks ranging from validating the key on opening of the application (and not during keying in the reigstration information itself) to having the keyverification happen on the server (C***Ftp style ;-)).

But again as history proves, every single scheme is broken, except the latest ones that involves strong crypto algos (like PK)...

So, my suggestion would be:

(1) Implement a strong algorithm in the first place
(2) Expect your algorithm to be reversed
(4) Have a plan "b" always

Hope all this rambling makes sense....

Signed,
-- FoxThree

not to me

If I get you right you give my decrypt a random string (S1) and then sees what that decrypts to. (S2)
Then you look at S1, S2 and the decryption algo. from that you figure out the encryption which you use in the key-generator. The decryption algorithm is not used in the key-generator at all (just to be sure of it)

It depends on what kind of cipher you're using. If it's symmetric, like DES, then the encryption alg is the same as the decryption alg in reverse. In order to check the encryption, the key has to be embedded in the code, so you make it possible for others to reverse out the key and use it in a keygen.

If you use public-key algorithms, then your method works just fine. You encrypt some data with your private key (i.e. you sign the data) and the public key in the program verifies it. This is how digital certificates in Netscape & Internet Explorer work.

The problem is, the person running the program isn't concerned about the actual validity of the certificate; in fact, he wants the program to run on a fake one. So he could put a different public key in for which he knows the private key, or NOP the check against the valid string, or change the valid string, or any number of other things.

Checksumming helps a lot in this case--you initialize variables in your program with data from the decryption key and the valid string, etc., so if they change anything, the program quits working.