Extending CryptoAPI

The CryptoAPI has been designed very carefully to be easily extensible. New types and parameters can be defined by any CSP author so as to make the CryptoAPI bend to the requirements of a wide variety of situations. Among the items that can be extended are:

• Provider types—Every provider type represents a particular family or type of cryptographic services. It is envisioned that many new provider types will be defined, each servicing a particular niche.
• Provider parameters—These packages of data are sent/received via CPSetProvParam and CPGetProvParam. Defining new parameters allows your CSP to be configured in ways not thought of by the CryptoAPI designers.
• Algorithm identifiers—New symmetric, public-key, and hash algorithms can be defined at any time. The enumeration facilities of CPGetProvParam allow applications to dynamically become aware of them.
• Public/private key pair types—As of this writing, only signature and key exchange key pair types have been defined. New types can be defined as needed.
• Key blob types—New key blob types can be defined, potentially permitting session keys, public keys, and public/private key pairs to be exchanged in a very flexible manner using the CPExportKey and CPImportKey functions.
• Key parameters—These packages of data are sent/received via CPSetKeyParam and CPGetKeyParam. New parameters can be defined, allowing for the support of many different types of keys.
• Hash object parameters—These packages of data are sent/received via CPSetHashParam and CPGetHashParam. New parameters can be defined, allowing for the support of many different types of hashes.
• Flag values—Every CryptoAPI/CryptoSPI function has a dwFlags parameter. New flags can be defined so that the behavior of each function can be modified as necessary. Extensions to CryptoAPI should be made in a responsible manner. Before defining a bunch of new parameters and algorithm types, you should consult with the people at Microsoft, so that:
  • Common CryptoAPI extensions can be identified and placed into the standard Win32 WINCRYPT.H header file.
  • Namespace collisions can be avoided.
  • A determination can be made as to whether the extension is really required, or whether the particular operation can be achieved with the current API.

Important  If you want your CSP to be compatible with applications developed for the Microsoft Base Cryptographic Provider, you must support all of the preceding items as they described in the CryptoAPI Reference and in this CSP Reference. For the details, see the CryptoAPI Reference Overview and the RSA/Full CSP Reference Overview.