Jan 26, 2011  Rather it will simply generate a new session identifier so we lose all the information that was in the original session. So right now everything works great if you first land on an ASP.NET page to start the session, but it all falls apart if you first land on a PHP page, or more importantly at the moment if you do a login via the PHP code. Generate a Session Key to Start a Support Session in the iOS Rep Console. One method to start a support session is for your customer to submit a one-time, randomly generated session key on your public site. Depending upon your account permissions, you can generate session keys for this purpose.

-->The CryptDeriveKey function generates cryptographic session keys derived from a base data value. This function guarantees that when the same cryptographic service provider (CSP) and algorithms are used, the keys generated from the same base data are identical. The base data can be a password or any other user data.

This function is the same asCryptGenKey, 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.

Syntax

Parameters

hProv

A HCRYPTPROV handle of a CSP created by a call toCryptAcquireContext.

Algid

AnALG_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, seeALG_ID.

For more information about ALG_ID values to use with the Microsoft Base Cryptographic Provider, seeBase Provider Algorithms. For more information about ALG_ID values to use with the Microsoft Strong Cryptographic Provider or the Microsoft Enhanced Cryptographic Provider, seeEnhanced Provider Algorithms.

hBaseData

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 withCryptCreateHash and then add the base data to the hash object withCryptHashData. This process is described in detail inHashes and Digital Signatures.

dwFlags

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.

Value	Meaning
CRYPT_CREATE_SALT	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 theCryptGetKeyParam 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. When keys with nonzero salt values are exported (by usingCryptExportKey), the salt value must also be obtained and kept with the key BLOB.
CRYPT_EXPORTABLE	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.
CRYPT_NO_SALT	This flag specifies that a no salt value gets allocated for a 40-bit symmetric key. For more information, see Salt Value Functionality.
CRYPT_UPDATE_KEY	Some CSPs use session keys that are derived from multiple hash values. When this is the case, CryptDeriveKey must be called multiple times. Key generator free download for microsoft office 2010. 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.
CRYPT_SERVER 1024 (0x400)	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.

phKey

A pointer to a HCRYPTKEY variable to receive the address of the handle of the newly generated key. When you have finished using the key, release the handle by calling the CryptDestroyKey function.

Return value

If the function succeeds, the function returns nonzero (TRUE).

If the function fails, it returns zero (FALSE). For extended error information, callGetLastError.

The error codes prefaced by 'NTE' are generated by the particular CSP being used. Some possible error codes are listed in the following table.

Return code	Description
ERROR_INVALID_HANDLE	One of the parameters specifies a handle that is not valid.
ERROR_INVALID_PARAMETER	One of the parameters contains a value that is not valid. This is most often a pointer that is not valid.
NTE_BAD_ALGID	The Algid parameter specifies an algorithm that this CSP does not support.
NTE_BAD_FLAGS	The dwFlags parameter contains a value that is not valid.
NTE_BAD_HASH	The hBaseData parameter does not contain a valid handle to a hash object.
NTE_BAD_HASH_STATE	An attempt was made to add data to a hash object that is already marked 'finished.'
NTE_BAD_UID	The hProv parameter does not contain a valid context handle.
NTE_FAIL	The function failed in some unexpected way.
NTE_SILENT_CONTEXT	The provider could not perform the action because the context was acquired as silent.

Remarks

When keys are generated for symmetricblock 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 theCryptSetKeyParam function.

The CryptDeriveKey function completes the hash. After CryptDeriveKey has been called, no more data can be added to the hash. Additional calls toCryptHashData orCryptHashSessionKey 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.

Let n be the required derived key length, in bytes. The derived key is the first n bytes of the hash value after the hash computation has been completed by

How Are Session Keys Generated Windows 10

CryptDeriveKey. If the hash is not a member of the SHA-2 family and the required key is for either 3DES or AES, the key is derived as follows:

1. 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.
2. 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.
3. 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.
4. 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.
5. Concatenate the result of step 3 with the result of step 4.
6. Use the first n bytes of the result of step 5 as the derived key.

The default RSA Full Cryptographic Service Provider is the Microsoft RSA Strong Cryptographic Provider. The default DSS Signature Diffie-Hellman Cryptographic Service Provider is the Microsoft Enhanced DSS Diffie-Hellman Cryptographic Provider. Each of these CSPs has a default 128-bit symmetric key length for RC2 and RC4.

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 Base	DES	56	56	56
MS Enhanced	RC4 and RC2	40	128	128
MS Enhanced	DES	56	56	56
MS Enhanced	3DES 112	112	112	112
MS Enhanced	3DES	168	168	168
MS Strong	RC4 and RC2	40	128	128
MS Strong	DES	56	56	56
MS Strong	3DES 112	112	112	112
MS Strong	3DES	168	168	168
DSS/DH Base	RC4 and RC2	40	40	56
DSS/DH Base	Cylink MEK	40	40	40
DSS/DH Base	DES	56	56	56
DSS/DH Enh	RC4 and RC2	40	128	128
DSS/DH Enh	Cylink MEK	40	40	40
DSS/DH Enh	DES	56	56	56
DSS/DH Enh	3DES 112	112	112	112
DSS/DH Enh	3DES	168	168	168

How Are Session Keys Generated Water

Examples

For an example that uses this function, see Example C Program: Deriving a Session Key from a Password.

Requirements

Minimum supported client	Windows XP [desktop apps only]
Minimum supported server	Windows Server 2003 [desktop apps only]
Target Platform	Windows
Header	wincrypt.h
Library	Advapi32.lib
DLL	Advapi32.dll

See also

Session keys differ from typical keys in one major way; they are created to exist for a very short time. Unlike a normal key, which may be used without alterations for years, a session key is only meant to be used for a few seconds to a few hours. For instance, a key is generated when a user connects to check his email and then is discarded when he logs off. This gives these keys a variety of advantages and drawbacks that are unique to this encryption style.

Their major advantage is their volume. Since every communication session uses a unique key, even an average-sized company can generate hundreds of keys every day. The sheer number of keys a potential attacker would need to sift through just to access important information is immense. While any given session key may be relatively easy to break, the likelihood of that random key having important information is very low.

How Are Session Keys Generated Water

One of the major influences on the ease of key breaking is the amount of encrypted material that may be used for reference. The more material available, the easier it is to break. Since a session key has a very small amount of reference material, the simplicity of the key is less important.

How Are Session Keys Generated Energy

On the other hand, session keys are well-known for poorly-made algorithms and easily-broken codes. This becomes especially apparent when attackers actually start to find patterns in the key generation or reverse engineer the actual algorithm. In either of these cases, the session key system breaks wide open, providing no security at all.