"Dr. Stephen Henson" wrote: > > As you've no doubt realised such license schemes are not very secure.
Right, but it's going to be a lot better than nothing. :) > A few well placed NOPs will circumvent many of them. This seems to be the main weakness in just about any license key scheme, i.e. hacking the binary to do whatever you want. > Equally replacing the public > key with a known one would also work. Well, I intend to have the public key embedded in the code, not in a file that the user can toy with. Of course, that's susceptible to binary hacking as well. > The code can be obfuscated and called at > various times but it is at best security by obscurity. Again, it's better than what I've got now - nothing. If you have in mind different methods I should be trying, I'm all ears. > If you really want to do things that way then you should sign a digest using > the documented EVP_Sign*() functions. The "dgst" command can use them for > signing. OK, I'll take a look at those. One thing I like about that is that I can have a cleartext license file. The way I was experimenting with it caused me to have a license file that was human-unreadable. > As for step 5 well this is just loading a public key into a EVP_PKEY > structure. This has been asked and answered several times. In outline: > > 1. Convert public key to DER. > 2. Convert binary DER file to a C structure using xxd. > 3. Convert public key to EVP_PKEY structure using d2i_PUBKEY(). OK, I'll dig around for some coding examples. Thanks! -- Griff Miller II | | Manager of Information Technology | "This space has been blankly | Positron Corporation | left intentional." | [EMAIL PROTECTED] | | ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
