A place to discuss the Windows Cryptography API
Question: Has anybody used the Windows Cryptography API in conjunction with VFP tables?-- Steven Black
[2002 Yes. And I'll be doing a presentation on it at the VancouverFoxproUserGroup and a magazine article is in the works. -- Alex Feldstein
(That article was later published in CoDe Magazine: http://feldstein.net/CodeCryptoArticle.htm)
[2004.06.26] A common problem when using the Windows Crypto API is an incompatibility between different versions of Windows. This has to do with a change in the US Government restrictions on Cryptography export laws. Before they lifted the restrictions, Win98 and before had a limit of 40-bits. Now Windows comes with 128-bit encryption so both are not compatible. But that is easily fixable.
What you have to do is make sure that you always use the Microsoftís Enhanced Cryptographic Provider (rsaenh.dll)
Run regedt32.exe and look for
Microsoft Base Cryptographic Provider v1.0
-- Alex Feldstein
Below is what we found out from the Windows Base Security technical person. The problem is that the Crypto API and Windows XP doesnít work well with NT 4.0 domain controllers. According to the Security tech:
On Windows XP, the Data Protection APIs are modified to encrypt user data with the userís password, but on previous OSís, this data was encrypted with the machineís secret. Thus, system modules that use the Data Protection APIs such a Crypto API and EFS are affected by this change in the Windows XP operating system.
On a Windows 2000 Server domain, there is a backup of the master key file used to decrypt the data. On an NT 4.0 domain, the backup master key file does not exist which is why changing the password on a NT 4.0 domain can cause unwanted behavior on EFS and Crypto API.
The following article discusses the issue http://support.microsoft.com/default.aspx?scid=kb;[LN];309408.
A possible workaround to the problem is to have Windows XP behave like Windows 2000. In this scenario, Windows XP will encrypt the Crypto Key container with the machineís secret rather than the userís password. This involves adding a registry value called MasterKeyLegacyNt4Domain. The article http://support.microsoft.com/default.aspx?scid=kb;EN-US;331333 discusses the registry key setting.
The other customer is looking at these articles (see links above), which provide excellent information, and maybe tomorrow we can change the registry entry to see that it works here also. After reading these two articles, we can now see why this behavior is occurring. Please call if you have any questions, otherwise I will let you digest this material and we can chat tomorrow.
Microsoft FoxPro Developer Support
And for those that need to deal with pre-existing workstation profiles:
I just checked on the question of what we can do with the User profiles.
Below is a way to change multiple profiles at one time. I hope they
help. I have copied the articles down below.
1. Have one person log on, make the changes that they need to the user
settings, and log off.
2. You will need to change the permissions on the ntuser.dat that you
have configured above.
3. The following articles show the basics of how to do this.
146050 - Modifying Ntuser.dat Hive So New Users Get Defined Settings
156697 - How to Update Permissions for User Profiles
4. Finally you will need to copy the changed profile to the Default
- William Fields
Alex, I'd be very interested in the information. I'm looking at using Crypto API right now. Am I correct that I should start thinking of storing data in memo fields as a result of the bloat caused by the digest? -- Doug Dodge
It's a matter of semantics. That's basically a hash. Not a 'map' to the information. I don't understand your question. If you store data in a DBF, you can encrypt fields or the dbf as a file. If we are talking of memo data, it's just plain text and an encrypted BLOB would not be that much bigger, depending on algorithm an key length. What are you looking to do? Create a hash to validate the information has not been tampered with? Encrypt the memo data so it can be decrypted later? Are we talking of text data or a general memo with a BLOB (like an image file for example) to begin with?
[2002.05.13 01:21:39 PM EST] Well, I have since discovered that there are at least two ways to call the Crypto API, Session Stream and Session Block. Session Stream keeps the same sized output whereas Session Block 'ups' the size to the next block size. My concern was whether or not I'd need to revisit my table field sizes in order for encryption to affectively take place. Apparently with Session Stream if I send nine (9) characters in I get nine back. -- Doug Dodge
A useful article and complete example can be found at:
-- Russ Menapace
For beginners, an introduction to cryptography can be found here: http://www.cryptographyworld.com -- Neil Philips
-- Alex Feldstein
I did this whole fancy VFP/WIN CRYPTO thing and it fell apart when we sorta merged Windows Active Directory into our lame-butt Novell network. The reality is in a poorly integrated Novell/Windows environment (a reason to avoid Novell, IMO) is that when the user changes their password in Novell and it doesn't get changed in Windows the encryption breaks. I really don't understand it and our IT people are lame Novell synchophants, so it's beyond fixing.
The purpose of the encryption was to encrypt/decrypt sensitive password/userid data in SQL Server. I've turned off the encryption and need to find the time to incorporate XPCrypt into the SQL Server.
I feel like I got away easy. I can obfuscate the SQL Server data by creating connection strings on the fly and have the data in SQL Server as cleartext. However, if I was using VFP tables the data would be exposed.
Sure, this only applies in a mixed network of Novell/Windows and maybe that's the lesson. What does Novell really have to offer anymore? Sure, their file servers are faster, but IMO it's about integration. It's about using NT Authentication to connect to SQL Server, IIS, or whatever. Novell is just file servers and print services these days and so what.
[2006.01.04] We're in the same boat. The workaround I've come up with for lack of a real solution is to delete this folder when the user cannot decrypt from within my app:
C:\Documents and Settings\USERNAME\Application Data\Microsoft\Crypto\RSA\
This might not be a good idea for commercial apps, but for internal ones it does the trick. Subsequent encryption/decryption calls recreate the folder and all is well and fine in cryptoland.
[2005.10.31] An alternative is Craig Boyd's Encrypt / Decrypt functions for VFP (vfpencryption.fll):
which offers AES and Blowfish algorithms. -- Alex Feldstein
Does anyone know how to get 256bit encryption out of the Crypto API object?
Is it a function of Key length?
Dear William Fields Good Sir from Above:
I am having spent many hours on this Very Serious problem with the Windows Crypto API, and as such, my self and my body are now tired. You, Sir, provide me with the most Powerful Help on the internet. You're idea is the WORK GOOD! I am now so very happy and i am go to the Pray for You. My wife is joyful and my child is say you are Nice Man. I hope to you have many of the Good today.
Kebab King from Jackson Heights
Category Windows API Category Encryption
( Topic last updated: 2007.01.18 10:52:41 AM )