>>>Is the API always available on W98+ operating systems or should one include it in an installation routine just to make sure?
>>
>>Should be included since Win98 2nd Ed. but never hurts to check. There is an issue on conmpatibility between different OS versions that I'll talk about later. It involves checking the registry.

>Ok.. That I can deal with. Knowing where to find the proper info would be helpful.

There are different providers included in the CAPI. The most common is the Microsoft Base Cryptographic Provider which is the initial cryptographic service provider (CSP), and is distributed with CryptoAPI versions 1.0 and 2.0. It is a general-purpose provider (generally using 40-bit keys) that supports digital signatures and data encryption. This provider is included with NT/Win2K/XP/Win95/Win98. As the basic provider you will have it in those OS and it can be exported. The CAPI also ofers other CSPs but not all are included in every Windows version and some are stronger and subject to export laws.

If you stick with the basic (which is powerful enough for most all of what you might need), you should be OK.

Note: In my previous message, I mistakenly referred to Win 98 2nd Ed. I was thinking of Win 95 OSR2.



>>>Is is possible with the CryptoAPI to create a hash? That is, create some encrypted info that's not able to be unencrypted but can be verified? Maybe I don't have my terms well defined but I seem to remember that when something is hashed it is forward encrypted but cannot be backwards unencrypted but you can still forward encrypt the password and then compare?
>>
>>Yes. You are correct. There are algorithms (included in the CAPI) that do a one-way hash. Will expand later.
>
>Excellent! This helps secure your security.

You can use a one-way hash to validate a message (or file) and make sure that it has not been tampered with. It is what you could do with an older-simple CRC or CRC32 but much more secure as it uses cryptography. The most common ones as RC4 and SHA, the later being the preferred one. Either one will do for most applications.


>>>What about the passing of keys around? I have often thought that a dual system of public/private kesy would be the best. That way the local, secondary public key can change at random times to increase the difficulty in spoofing a system. I don't know if this makes sense but the idea is to encrypt the key with a key, then change the key....
>>
>>That is the basic premise of PKI (Public Key Infrastructure). You keep your private key secret and you publish your Public key. That is exactly what PGP does. The Public key does not change. It is not possible and not needed. You can revoke your public key, generate a new private-public key pair and publish your new public key if needed.
>
>Right. Lessee if I can get this right.. <g> In our case we're thinking of a two-level, dual-key approach. IOW, we'll stash the new public key (level 1) on the local computer and the public key (level 2) for that specific computer encrypted with the matching private key for the specific local public key stashed on the local computer. That way the local computer would be the only computer that could unencrypt the public key (level 2) stored on the local computer, which in turn would be the only computer that could unencrypt the data which via the private key stashed on the server.
>
>IOW, once a SSL connection has been made and basic authentication done the local public key (level 1) would then unencrypt the public key (level 2) which could be used against the encrypted data that had been encrypted by the private key (level 2) and stored in an encryted form on the server. The encrypted data would be transferred to the local computer (and back) and unencrypted only locally. The data one the server would always be encrypted and each transaction would have a separate set of public/private (level 2) keys that could be dynamically updated.
>
>Authentication data can be encrypted/unencrypted via the level 2 key set I think.
>
>This way I can change the data and the data dynamically.

Huh?

>I don't know if this makes any sense and I've probably got it wrong but hopefully I've made at least a little sense.

You do make it sound complicated!

This is the basics of PKI:
I create a private key/public key pair. I give you my public key (or publish it in a server like MIT's, or write it in the New York Times for everyone to see). You do the same.

Then, in order for me to encrypt a message that only you can read, I encrypt it using my private key and your public key. Anybody intercepting the message would not be able to read it because it is encrypted with your public key. In order for you to decrypt it you have to type your private key (really a passphrase of certain complexity) that matches your public key.

What you are proposing is a second set in the middle where the message has to be re-encrypted? Don't see why you need that. The message is encrypted at all points (wouldn't even need SSL here) and only the originator and the recipient would be able to read it as they exchanged keys and they are trusting that each other's public key really belongs to the other party and not to a third man-in-the-middle.

In your case of course your keys will be somewhat predictable cause you have a one-track mind but that is something for a thread in another section. <g>