This function is the same as CryptGenKey, except that the generated session keys are derived from base data instead of being random. CryptDeriveKey can only be used to generate session keys. It cannot generate public/private key pairs.
A handle to the session key is returned in the phKey parameter. This handle can be used with any CryptoAPI function that requires a key handle.
BOOL CryptDeriveKey( HCRYPTPROV hProv, ALG_ID Algid, HCRYPTHASH hBaseData, DWORD dwFlags, HCRYPTKEY *phKey );
An ALG_ID structure that identifies the symmetric encryption algorithm for which the key is to be generated. The algorithms available will most likely be different for each CSP. For more information about which algorithm identifier is used by the different providers for the key specs AT_KEYEXCHANGE and AT_SIGNATURE, see ALG_ID.
For more information about ALG_ID values to use with the Microsoft Base Cryptographic Provider, see Base Provider Algorithms. For more information about ALG_ID values to use with the Microsoft Strong Cryptographic Provider or the Microsoft Enhanced Cryptographic Provider, see Enhanced Provider Algorithms.
A handle to a hash object that has been fed the exact base data.
To obtain this handle, an application must first create a hash object with CryptCreateHash and then add the base data to the hash object with CryptHashData. This process is described in detail in Hashes and Digital Signatures.
Specifies the type of key generated.
The sizes of a session key can be set when the key is generated. The key size, representing the length of the key modulus in bits, is set with the upper 16 bits of this parameter. Thus, if a 128-bit RC4 session key is to be generated, the value 0x00800000 is combined with any other dwFlags predefined value with a bitwise-OR operation. Due to changing export control restrictions, the default CSP and default key length may change between operating system releases. It is important that both the encryption and decryption use the same CSP and that the key length be explicitly set using the dwFlags parameter to ensure interoperability on different operating system platforms.
The lower 16 bits of this parameter can be zero or you can specify one or more of the following flags by using the bitwise-OR operator to combine them.
Typically, when a session key is made from a hash value, there are a number of leftover bits. For example, if the hash value is 128 bits and the session key is 40 bits, there will be 88 bits left over.
If this flag is set, then the key is assigned a salt value based on the unused hash value bits. You can retrieve this salt value by using the CryptGetKeyParam function with the dwParam parameter set to KP_SALT.
If this flag is not set, then the key is given a salt value of zero.
If this flag is set, the session key can be transferred out of the CSP into a key BLOB through the
CryptExportKey function. Because keys generally must be exportable, this flag should usually be set.
If this flag is not set, then the session key is not exportable. This means the key is available only within the current session and only the application that created it is able to use it.
This flag does not apply to public/private key pairs.
||This flag specifies that a no salt value gets allocated for a 40-bit symmetric key. For more information, see Salt Value Functionality.|
Some CSPs use session keys that are derived from multiple hash values. When this is the case, CryptDeriveKey must be called multiple times.
If this flag is set, a new session key is not generated. Instead, the key specified by phKey is modified. The precise behavior of this flag is dependent on the type of key being generated and on the particular CSP being used.
Microsoft cryptographic service providers ignore this flag.
||This flag is used only with Schannel providers. If this flag is set, the key to be generated is a server-write key; otherwise, it is a client-write key.|
If the function succeeds, the function returns nonzero (TRUE).
If the function fails, it returns zero (FALSE). For extended error information, call GetLastError.
The error codes prefaced by "NTE" are generated by the particular CSP being used. Some possible error codes are listed in the following table.
||One of the parameters specifies a handle that is not valid.|
||One of the parameters contains a value that is not valid. This is most often a pointer that is not valid.|
||The Algid parameter specifies an algorithm that this CSP does not support.|
||The dwFlags parameter contains a value that is not valid.|
||The hBaseData parameter does not contain a valid handle to a hash object.|
||An attempt was made to add data to a hash object that is already marked "finished."|
||The hProv parameter does not contain a valid context handle.|
||The function failed in some unexpected way.|
||The provider could not perform the action because the context was acquired as silent.|
When keys are generated for symmetric block ciphers, the key by default is set up in cipher block chaining (CBC) mode with an initialization vector of zero. This cipher mode provides a good default method for bulk-encrypting data. To change these parameters, use the CryptSetKeyParam function.
The CryptDeriveKey function completes the hash. After CryptDeriveKey has been called, no more data can be added to the hash. Additional calls to CryptHashData or CryptHashSessionKey fail. After the application is done with the hash, CryptDestroyHash must be called to destroy the hash object.
To choose an appropriate key length, the following methods are recommended.
- To enumerate the algorithms that the CSP supports and to get maximum and minimum key lengths for each algorithm, call CryptGetProvParam with PP_ENUMALGS_EX.
- Use the minimum and maximum lengths to choose an appropriate key length. It is not always advisable to choose the maximum length because this can lead to performance issues.
- After the desired key length has been chosen, use the upper 16 bits of the dwFlags parameter to specify the key length.
- Form a 64-byte buffer by repeating the constant 0x36 64 times. Let k be the length of the hash value that is represented by the input parameter hBaseData. Set the first k bytes of the buffer to the result of an XOR operation of the first k bytes of the buffer with the hash value that is represented by the input parameter hBaseData.
- Form a 64-byte buffer by repeating the constant 0x5C 64 times. Set the first k bytes of the buffer to the result of an XOR operation of the first k bytes of the buffer with the hash value that is represented by the input parameter hBaseData.
- Hash the result of step 1 by using the same hash algorithm as that used to compute the hash value that is represented by the hBaseData parameter.
- Hash the result of step 2 by using the same hash algorithm as that used to compute the hash value that is represented by the hBaseData parameter.
- Concatenate the result of step 3 with the result of step 4.
- Use the first n bytes of the result of step 5 as the derived key.
The following table lists minimum, default, and maximum key lengths for session key by algorithm and provider.
|Provider||Algorithms||Minimum key length||Default key length||Maximum key length|
|MS Base||RC4 and RC2||40||40||56|
|MS Enhanced||RC4 and RC2||40||128||128|
|MS Enhanced||3DES 112||112||112||112|
|MS Strong||RC4 and RC2||40||128||128|
|MS Strong||3DES 112||112||112||112|
|DSS/DH Base||RC4 and RC2||40||40||56|
|DSS/DH Base||Cylink MEK||40||40||40|
|DSS/DH Enh||RC4 and RC2||40||128||128|
|DSS/DH Enh||Cylink MEK||40||40||40|
|DSS/DH Enh||3DES 112||112||112||112|
For an example that uses this function, see Example C Program: Deriving a Session Key from a Password.
|Minimum supported client||Windows XP [desktop apps only]|
|Minimum supported server||Windows Server 2003 [desktop apps only]|