Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFPEncryption question
Message
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2000 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01136407
Message ID:
01138293
Views:
15
In the case you have outlined I would do it like the following...

http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,34321a75-a1fc-4a0e-a9af-17a3c6916d90.aspx

There are no plans to provide the feature you're asking for. However, and I think I read someone else's post that elluded to this, why not use a hash to solve this? For instance, here's a simplistic example where neither the plaintext, key, or ciphertext would be anywhere in the code and yet you could still check that the user entered in the right key (seeing 'DC2F6812CFD76CF41A287FC4F4B0A3213BE094AD' in the code does a hacker no good as it is just a message digest):
*!* Here's how you check what the user entered
?CheckUserLicense("12345555666677778888") && user entered a license let's check it
?CheckUserLicense("11113333444455556666") && user entered another license let's check it

*!* In application itself would be the following function
*!* Note that neither the key, the plaintext, or even the ciphertext
*!* exists in the function. We will use what the user entered in
*!* and check the hash of the resulting ciphertext
************************************
FUNCTION CheckUserLicense(tcEnteredByUser)
************************************
LOCAL lcPlaintext, lcSecretKey, lcCipherText, lcMessageDigest, llReturn
m.lcPlaintext = LEFT(m.tcEnteredByUser,4)
m.lcSecretKey = Right(m.tcEnteredByUser,16)
SET LIBRARY TO LOCFILE("vfpencryption71.fll")
m.lcCipherText = Encrypt(m.lcPlaintext, m.lcSecretKey, 0, 0)
m.lcMessageDigest = STRCONV(Hash(m.lcCipherText,1),15)
m.llReturn = m.lcMessageDigest = "DC2F6812CFD76CF41A287FC4F4B0A3213BE094AD" && see below
RETURN m.llReturn

*!* In preparation we need to get the hex equivalent of a hash
*!* this would be done during development and would not appear in the application
*!* source code
*!*	LOCAL lcPlaintext, lcSecretkey, lcCipherText, lcMessageDigest
*!*	SET LIBRARY TO LOCFILE("vfpencryption71.fll")
*!*	m.lcPlaintext = "1111"
*!*	m.lcSecretkey = "3333444455556666"
*!*	m.lcCipherText = Encrypt(m.lcPlaintext, m.lcSecretKey, 0, 0)
*!*	m.lcMessageDigest = STRCONV(Hash(m.lcCipherText,1),15)
*!*	_cliptext = m.lcMessageDigest && put the message digest on the clipboard so we can paste it into our CheckUserLicense
>>You'd need to check that the right key was used. If a way to tell whether the correct key was used was added to the library this would decrease the overall security of the library by making it succeptible to brute force attacks among other things (the library would have to embed the key in the ciphertext so it could check it and this would not be a good thing). If you don't know what the right key should be or what the resultant plaintext should be when decrypting the ciphertext then there is no way to know whether the key used is the right one.
>>
>>Perhaps you could explain a little more about what you are trying to do and why not having the ability to know whether the correct key was used is causing you a problem (or why you feel that such a feature would be useful to you)?
>>
>
>
>Thanks for the reply!
>
>Suppose I have an application to distribute to users. The application requires a license to be activated on it's initial run. The user may download the software upon purchase and they will receive an email attached the license encrypted by a key generated uniquely for the customer. Of course, it wouldn't be wise or logical to store that key within the application. Therefore if there were a way to know that the decrytion failed with the key provided, certain measures may be taken in such an event. In this scenario, I could warn the user that the key provided is incorrect. I was expecting an error, exception or for Decrypt function to return .f. if not decrypted correctly because CryptDecrypt function in AdvAPI32.DLL returns zero (FALSE) and sets last error.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform