Currently, the following functions can be extended:
| CryptoAPI Function | OID Function Name Define | OID Function Name String |
|---|---|---|
| CryptEncodeObject | CRYPT_OID_ENCODE_ OBJECT_FUNC |
"CryptDllEncodeObject" |
| CryptDecodeObject | CRYPT_OID_DECODE_ OBJECT_FUNC |
"CryptDllEncodeObject" |
| CertOpenStore | CRYPT_OID_OPEN_ STORE_PROV_FUNC |
"CertDllOpenStoreProv" |
| CertVerifyCTLUsage | CRYPT_OID_VERIFY_ CTL_USAGE_FUNC |
"CertDllVerifyCTLUsage" |
| CertVerifyRevocation | CRYPT_OID_VERIFY_ REVOCATION_FUNC |
"CertDllVerifyRevocation" |
To extend the functionality of one of these CryptoAPI functions, a new function, containing the new functionality, must be created in a DLL and be registered in the registry or installed in memory.
As shown in the previous illustration, when one of the listed functions gets called with the newly designated OID and encoding type, the new function gets called rather than calling one of the functions provided as part of the CryptoAPI.
The name of the newly developed function can be either that listed under "OID Function Name String" in the previous table, or a different name can be used at the time the function is registered. In either case, however, the new function's prototype must match that of the listed function. In all the cases except for CertOpenStore, this prototype is the same as the CryptoAPI calling function. In the case of CertOpenStore, the prototype is as follows:
BOOL WINAPI CertDllOpenStoreProv(
IN LPCSTR lpszStoreProvider,
IN DWORD dwMsgAndCertEncodingType,
IN HCRYPTPROV hCryptProv,
IN DWORD dwFlags,
IN const void *pvPara,
IN HCERTSTORE hCertStore,
IN OUT PCERT_STORE_PROV_INFO pStoreProvInfo
);
Be aware that if the prototypes do not match, the system stack will get corrupted.
In addition to providing the new function in a DLL, when extending the functionality of CryptEncodeObject or CryptDecodeObject, a type definition for the new C data structure must be placed in a header file that gets included when the user's program is compiled.