On 12/29/2009, at 09:09 PM, Markus Spoettl wrote: >> This *heavily* depends on your algorithm. If you generate a key from the >> user’s name and email address, then the probability is equal to 0 that a >> legit and a generated serial number will collide. > > Well, you don't use the license data to derive a key from it. No sensible > solution does that.
Why not? What speaks against it? >> The damage of both techniques can be equal. And I don’t know if recommending >> a framework to prevent piracy is a good advice at all. I’m not against any >> framework, but a self-baked solution would be more unique and require more >> effort to crack—under the assumption that you have enough knowledge and time. > > 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. I think you misunderstood me a little bit. Security by obscurity is one of the worst things that can happen, so I added the prerequisite that you need enough knowledge and time. You can also use RSA in your own solution, nothing speaks against it. > 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. > > Using this system instead of something home-baked has the huge advantage of > being reliable and tested for years. Plus, the actual decrypting code doesn't > have to be secret (in fact it is not) because the only really valuable > information is the private key (which is not embedded in the application). > > That said, AquaticPrime (and I imagine other systems mentioned here) don't > provide much help to put the license checking code into your app in a way > that makes it difficult to remove. You can make it easy for crackers or more > difficult. In the end the license check - no matter how sophisticated - boils > down to a check which can fail or succeed. If a cracker finds it, it can be > removed. I understand how asymmetric crypto license systems work, but my point was that at the end it doesn’t matter what you use and if people distribute a crack or a keygen. I highly appreciate the work of AquaticPrime and other similar frameworks, but these kind of frameworks are also a problem. If a cracker understands once how AquaticPrime works he will produce cracks for other applications which use AquaticPrimie much faster in the future—once you understand something everything seems to be easy-peasy. Rafael Chief Sucker at Juicy Cocktail http://www.juicycocktail.com/ ------------------------------------ MacSB email guidelines: http://tinyurl.com/2g55d6 Use MacSB-Talk for off topic messages: http://groups.google.com/group/macsb-talk Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/macsb/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/macsb/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
