5
$\begingroup$

I'd like to implement a "Product Registration" scheme into my software where upon initial use, the User must enter a key to unlock it.

The key they enter is compared to their encrypted Username.
They would have to acquire the key from myself if they wished to use the software. Their encrypted Username must be reasonably short so it's not too difficult for them to enter the key. They would however, only have to enter the key once.
(I'm aware this isn't actually how keys are issued)

What kind of encryption is appropriate for this?
(It needs to encrypt a string into letters and numbers only and be reasonably short).
There's no thought needed over decryption, since I'll only be comparing encrypted strings.

I'm basically looking for a cipher that produces the shortest code possible so that it's not tedious for the User to enter. (Though still difficult to break)

Any suggestions?
Thanks!

(You needn't worry over the actual security.
I'm a noob programmer and all my software is free anyway)

Improve this question
$\endgroup$
1
  • $\begingroup$ Where does the use obtain the key and the username? Could it be possible to use a one time pad for this? $\endgroup$
    – skub
    Commented Nov 15, 2011 at 5:15

3 Answers 3

Reset to default
1
$\begingroup$

If it's not necessary to think about security, etc, you could do the following:

  • the user sends you the username
  • you calculate the MD5 hash of his same + some salt you choose. Let's say, you do calculate MD5(username + "mySecretSalt"). Let's say the result is "5aa63b07a1a9f0b33d88e719e4cc9f86"
  • you take only the first 4 hex characters. For example, "5aa63b07". You send the user this "registration key"
  • when the user types it in the registration box, you calculate it again, compare, and you're done.

Of course that is very weak, there's problems of experienced users trying to look inside your code to see how it's done, etc. But you said you don't mind security at this time, so...

Improve this answer
$\endgroup$
5
  • $\begingroup$ Preferably use MAC(secret, username) instead of a simple hash (use HMAC, for example). $\endgroup$
    – Paŭlo Ebermann
    Commented Nov 14, 2011 at 12:03
  • 2
    $\begingroup$ @Paŭlo: Generally I'd agree, but in this case that's a bit like recommending the use of packing tape instead of office tape for holding a cardboard house together. Technically, your advice is good, but the hash is far from the weakest link here. $\endgroup$
    – Ilmari Karonen
    Commented Nov 14, 2011 at 16:02
  • $\begingroup$ I thought the OP just wanted a very simple "make the regular user contact me to get a very short key" kind of protection, and the solution I provided is more than enought for that. $\endgroup$
    – woliveirajr
    Commented Nov 14, 2011 at 16:52
  • $\begingroup$ That's what I originally intended to do, but with DES. Yeah, maybe I will. $\endgroup$
    – Anti Earth
    Commented Nov 14, 2011 at 21:20
  • 1
    $\begingroup$ If you're going to send binary data to the user, it makes sense to encode it in something other than hexadecimal. Take a look at Crockford's Base32, which avoids characters that can be confused easily. $\endgroup$
    – Stefano Palazzo
    Commented Nov 15, 2011 at 15:06
3
$\begingroup$

Since no-one else has mentioned this yet, I guess I should point out that it is possible to use public key signature schemes like (EC)DSA to generate software registration keys. For example, Microsoft apparently uses this for their product keys.

Basically, you embed the public key in your program and keep the private key, which you'll use to sign whatever information you want to tie the activation code to; this could be just a fixed string, but it could also include things like the name of the user or information about the computer they're using, depending on what kind of registration system you want.

The problem, as you correctly suggest in your post, is choosing a signature length long enough to be reasonably secure while short enough for users to type in. If you could have your users type in 64 random characters (out of a repertoire of 32 each), you'd be fine with a total signature length of 320 bits — but in practice, even 30 characters is a nuisance to type. Of course, if you're doing the registration online, you could just give the user a block of text to copy and paste.

Anyway, if your software is free anyway and you don't care about security, much simpler schemes (like woliveirajr's suggestion) will do just as well. But if that's the case, why make your users go through the nuisance of registration in the first place?

Improve this answer
$\endgroup$
1
  • $\begingroup$ The thrill of knowing who has the confidence in my software to use it :) $\endgroup$
    – Anti Earth
    Commented Nov 30, 2011 at 10:16
2
$\begingroup$

There a number of ways of using block ciphers to produce short ciphertexts: see this post and this post. A general technique is format preserving encryption (FPE).

I am not clear on the details of how you want to use it. Is the secret key being distributed with the software so that it can encrypt the username for comparison to the product key you supply?

Improve this answer
$\endgroup$
1
  • $\begingroup$ The software is distributed along with the Users encrypted Username. When they enter this, the program determines their Username, encrypts it and compares it. I think FPE is exactly what I'm looking for! $\endgroup$
    – Anti Earth
    Commented Nov 15, 2011 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.