On 29.12.2009, at 21:09, Markus Spoettl wrote: > Well, you don't use the license data to derive a key from it. No sensible > solution does that.
Actually, many do that, if they can. And it's actually good, because it means you can put the name and e-mail of the customer that bought a particular key into a visible spot in the application. If someone gives away the key, they also give away their name and e-mail address. Whether you do that by just hashing the e-mail or actually encoding it in the license is a matter of preference in key lengths. > No offense but: Quite the contrary. This is security by obscurity which is a > big no-no if you ever want something to be secure. RSA for that matter is > well known and reasonably hard. It's not clear whether both of you are talking about the same area here: 1) I agree with Markus that only people who are actively working on encryption and have studied and applied cryptology should try to come up with their own encryption algorithm. Just because nobody knows your algorithm so far doesn't mean they can't crack it using simple statistical methods (anyone can run an app in a debugger, so they know what the decrypted end result is supposed to be). RSA and others were designed to not allow that. 2) OTOH I agree with Rafael that using an established encryption and some basic precautions, it's OK to write your own licensing scheme. Some small differences mean that a general crack for AP won't apply to your app. Then again, you can achieve the same benefits by modifying AP. Maybe that'd be a better route. Many algorithms can be configured, e.g. by using nonstandard seed numbers. Unless you weaken the algorithm by using a bad number, this can actually be quite beneficial, because most factoring tools are built for the common case. > I believe you are not appreciating how AquaticPrime (and other asymmetric > crypto license systems) work: You (the developer) have 2 keys, one private > key which is secret and known only by you, one public key. The public key can > only be used to de-crypt the license but not to generate one. You use the > private key to create a license. > > You just can't develop a license key generator unless you have the private > key. It's not embedded in the application, no one knows it except you. And since these keys usually have fairly large sizes compared to a simple password, it can be quite difficult to factor (i.e. "reverse-engineer") such a key. With a decent key, it takes a year or so of CPU time, and usually you have one key per product. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://groups.yahoo.com/group/mac-gui-dev/
