>Ken:
>
>I noticed that you wrote about HIPPA certification in a prior e-mail, as well as electronic signatures.
>
>I have a medical system (EAP, Employee Assistance Program) that needs electronic signatures, and I'm having problems absorbing some concepts (somewhat like when OOP first appeared).
>
>Currently, I am loading the data (such as clinician notes and dates) that must be certified as not changing... into a variable, and hashing it using an .FLL called foxcrypto which uses the MD5 hashing algorithm. I believe that I am also supposed to include data that identifies the user and maybe the date it was signed.
>
>I see that CAPICOM may be the answer. I've been able to encrypt data with CAPICOM by using the EncryptData object. I can run the MD5 & CAPICOM Encryptdata algorithm in reverse, compare the data against the original and determine if the data is changed, but I'm lost when it comes to public and private keys, and the roll certificates play.
>
>It appears that a "private key" needs to be used somewhere in the encryption process. And that someone with a "public key" can verify that the data has not changed. Plus, it seems that there are certificates that supply these keys (???) on each machine, but how is a quandry for me.
>
>Can you help??
>
>Bob
We only use CAPICOM for testing since it is a 'windows-only' product. The rumor is that Medicare will approve an encryption scheme. If/when they do, we certainly will support it. The concept of the public/private key stuff is pretty simple. The implementation can be complex. The more complexity, the more chance for bugs and security problems. Anyway, Ed Rauh (on this list) has written some good information on the subject. Maybe he will contribute something (a class, writeup, etc) in the future.

To add to this, if you encrypt a file with your private key, then anyone with your public key can decrypt it and be certain that you encrypted it and it has not changed. So, you can see that if I encrypt a file with your public key and then encrypt that 'encrypted file' with my private key, then anyone can decrypt the file with my public key, but they will still have garbage. Only you can decrypt that 'decrypted file' with your private key. Hope that makes sense.

The problem is being certain that it is really your (and my) public key. That is where it gets complicated and you need a third party like verisign to verify the keys. These are stored on your computer in the certificate. Windows stores these certificates in the registry. Capicom makes the use of the certificates fairly easy. Windows does not solve the problem of verifying the owner of the keys (at least for my application). In order to use this in a medical provider's day to day business, there will need to be a very simple, federal government approved mechanism.