tags:

views:

224

answers:

2

I've been looking at this all day. I probably should have walked away from it hours ago; I might be missing something obvious at this point.

Short version: Is there a way to generate and boil down an asymmetrically encrypted hash to a reasonable number of unambiguous, human readable characters?

Long version:

I want to generate license keys for my software. I would like these keys to be of a reasonable length (25-36 characters) and easily read and entered by a human (so avoid ambiguous characters like the number 0 and the capital letter O).

Finally--and this seems to be the kicker--I'd really like to use asymmetric encryption to make it more difficult to generate new keys.

I've got the general approach: concatenate my information (user name, product version, a salt) into a string and generate a SHA1() hash from that, then encrypt the hash with my private key. On the client, build the SHA1() hash from the same information, then decrypt the license with the public key and see if I've got a match.

Since this is a Mac app, I looked at AquaticPrime, but that generates a relatively large license file rather than a string. I can work with that if I must, but as a user I really like the convenience of a license key that I can read and print.

I also looked at CocoaFob which does generate a key, but it is so long that I'd want to deliver it as a file anyway.

I fooled around with OpenSSL for a while but couldn't come up with anything of a reasonable length.

So...am I missing something obvious here? Is there a way to generate and boil down an asymmetrically encrypted hash to a reasonable number of unambiguous, human readable characters?

I'm open to buying a solution. But I work on a number of different of platforms, so I'd want something portable. Everything I've looked at so far has been platform specific.

Many, many thanks for a solution!

PS - Yes, I know it will still be cracked. I'm trying to come up with something reasonable that, as a user, I would still find friendly.

A: 

I would consider the MD5 algorithm. It's widely implemented and will generate a 32 character alphanumeric string regardless of the input size. Apply the algorithm to your SHA1 hash and it may be what you're looking for.

Kai
MD5 would only save four bytes over SHA1, and regardless it isn't encryption, just a hash. Anyone who figures out the input data would be able to generate their own license keys. By adding a private/public keypair, they won't be able to create new licenses without the private key. (They can still hack the binary, but that's a different problem)
starkos
A: 

Treat each SHA1 character as hex, perhaps drop any unnecessary formatting, (dashes or brackets), use some array mapping to convert 0-9A-F as say A-P in some random order, use that as your 'human' entered text. MD5 will give you your 32 chars or a few more for SHA1. Unmap the chars back to your SHA1/MD5 string/bytes and proceed from there.

andora
Okay, but the question was "Is there a way to...boil down an <b>asymmetrically encrypted</b> hash.
starkos
I don't think it matters how you arrive at the bytes/string, asymmetrically or not. The hash output is 'designed' to 'occupy' the bit-space, ie: 128 bits, 160 bits, etc. You either take it as-is, or post-process it: truncate it or boil-it-down anyway you choose, but you will lose the uniqueness of the hash or/and the cryptographic strength of the hash. A simple truncation should work and be 'good enough', providing internally you can compute the full hash to start with before you compare with a trucated part.
andora
Distributing a hash of an asymmetric key makes no sense; you'd have to include the private key in the client to verify the hash! I am computing a hash, then encrypting it, and *that* is my (long) license key.
starkos