EVP Key Agreement - Revision history

Jwalton: Add InfoBox.

2017-04-28T23:00:58Z

Add InfoBox.

Jwalton: Add links to all EVP articles.

2017-04-28T22:54:32Z

Add links to all EVP articles.

Matt: Modified manual links to point to the wiki manual pages

2013-05-07T20:44:31Z

Modified manual links to point to the wiki manual pages

Matt: moved EVP Key Derivation to EVP Key Agreement: OpenSSL uses the "derive" function to perform key agreement. However more generally this process is referred to as key agreement - derivation can mean other things. All a bit confusing. Changing n

2013-04-01T14:49:30Z

moved EVP Key Derivation to EVP Key Agreement: OpenSSL uses the "derive" function to perform key agreement. However more generally this process is referred to as key agreement - derivation can mean other things. All a bit confusing. Changing n

Matt: Change derivation to agreement

2013-04-01T14:47:53Z

Change derivation to agreement

Matt: Added further DH and ECDH Links

2013-04-01T14:44:37Z

Added further DH and ECDH Links

Matt: Added ECDH link

2013-03-31T22:05:02Z

Added ECDH link

Matt: Added DH and ECDH Links

2013-03-31T22:04:22Z

Added DH and ECDH Links

Philippe lhardy: /* See also */

2013-03-24T17:14:10Z

Matt: Added link to Diffie Hellman

2013-03-22T22:25:45Z

Added link to Diffie Hellman

← Older revision		Revision as of 23:00, 28 April 2017
Line 1:		Line 1:
		+	{{DocInclude
		+	\|Name=Key Agreement
		+	\|Url=http://wiki.openssl.org/index.php/Manual:Evp(3)
		+	\|Include=evp.h}}
		+
	Key agreement is the process of agreeing a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key agreement function such as [[Diffie Hellman\|Diffie-Hellman (DH)]] or [[Elliptic Curve Diffie Hellman\|Elliptic Curve Diffie-Hellman (ECDH)]]. Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.		Key agreement is the process of agreeing a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key agreement function such as [[Diffie Hellman\|Diffie-Hellman (DH)]] or [[Elliptic Curve Diffie Hellman\|Elliptic Curve Diffie-Hellman (ECDH)]]. Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.

@@ Line 47: / Line 47: @@
 * [[Diffie Hellman]]
 * [[Elliptic Curve Diffie Hellman]]
 [[Category:Crypto API]]
 [[Category:Examples]]
 [[Category:C level]]

@@ Line 38: / Line 38: @@
 You can only use EVP_PKEY types that support key agreement (currently only [[Diffie Hellman|DH]] and [[Elliptic Curve Diffie Hellman|ECDH]]). Clearly in the code sample above the shared secret needs to be "freed" with OPENSSL_free once it is no longer required.
-The OpenSSL documentation for the agreement functions is available here: http://www.openssl.org/docs/crypto/EVP_PKEY_derive.html. There is also an example of usage of the API on the [[Elliptic Curve Diffie Hellman]] page.
+The OpenSSL documentation for the agreement functions is available here: [[Manual:EVP_PKEY_derive(3)]]. There is also an example of usage of the API on the [[Elliptic Curve Diffie Hellman]] page.
 Note that shared secrets derived in this way may not be evenly distributed within the key space. For this reason a shared secret is typically passed through some further function such as a message digest such as SHA2 (possibly combining the shared secret with other well defined data first). Using a shared secret directly as an encryption key could lead to biases in your encryption implementation which in turn is likely to lead to security weaknesses. Refer to section 2.1.2 of [https://tools.ietf.org/html/rfc2631 RFC 2631] for an example of this in practice.

@@ Line 1: / Line 1: @@
-Key derivation is the process of deriving a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key derivation function such as [[Diffie Hellman|Diffie-Hellman (DH)]] or [[Elliptic Curve Diffie Hellman|Elliptic Curve Diffie-Hellman (ECDH)]]. Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.
+Key agreement is the process of agreeing a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key agreement function such as [[Diffie Hellman|Diffie-Hellman (DH)]] or [[Elliptic Curve Diffie Hellman|Elliptic Curve Diffie-Hellman (ECDH)]]. Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.
 The following code sample is from the OpenSSL manual and shows how a private/public key pair (stored in the variable pkey), and a public key of some peer (stored in the variable peerkey) can be combined to derive the shared secret (stored in the variable skey, with a length stored in skeylen). Obviously equivalent code would be executed on the peer side to come up with the same shared secret.
@@ Line 36: / Line 36: @@
 </pre>
-You can only use EVP_PKEY types that support key derivation (currently only [[Diffie Hellman|DH]] and [[Elliptic Curve Diffie Hellman|ECDH]]). Clearly in the code sample above the shared secret needs to be "freed" with OPENSSL_free once it is no longer required.
+You can only use EVP_PKEY types that support key agreement (currently only [[Diffie Hellman|DH]] and [[Elliptic Curve Diffie Hellman|ECDH]]). Clearly in the code sample above the shared secret needs to be "freed" with OPENSSL_free once it is no longer required.
-The OpenSSL documentation for the derivation functions is available here: http://www.openssl.org/docs/crypto/EVP_PKEY_derive.html. There is also an example of usage of the API on the [[Elliptic Curve Diffie Hellman]] page.
+The OpenSSL documentation for the agreement functions is available here: http://www.openssl.org/docs/crypto/EVP_PKEY_derive.html. There is also an example of usage of the API on the [[Elliptic Curve Diffie Hellman]] page.
 Note that shared secrets derived in this way may not be evenly distributed within the key space. For this reason a shared secret is typically passed through some further function such as a message digest such as SHA2 (possibly combining the shared secret with other well defined data first). Using a shared secret directly as an encryption key could lead to biases in your encryption implementation which in turn is likely to lead to security weaknesses. Refer to section 2.1.2 of [https://tools.ietf.org/html/rfc2631 RFC 2631] for an example of this in practice.

@@ Line 36: / Line 36: @@
 </pre>
-You can only use EVP_PKEY types that support key derivation (currently only DH and ECDH). Clearly in the code sample above the shared secret needs to be "freed" with OPENSSL_free once it is no longer required.
+You can only use EVP_PKEY types that support key derivation (currently only [[Diffie Hellman|DH]] and [[Elliptic Curve Diffie Hellman|ECDH]]). Clearly in the code sample above the shared secret needs to be "freed" with OPENSSL_free once it is no longer required.
-The OpenSSL documentation for the derivation functions is available here: http://www.openssl.org/docs/crypto/EVP_PKEY_derive.html.
+The OpenSSL documentation for the derivation functions is available here: http://www.openssl.org/docs/crypto/EVP_PKEY_derive.html. There is also an example of usage of the API on the [[Elliptic Curve Diffie Hellman]] page.
 Note that shared secrets derived in this way may not be evenly distributed within the key space. For this reason a shared secret is typically passed through some further function such as a message digest such as SHA2 (possibly combining the shared secret with other well defined data first). Using a shared secret directly as an encryption key could lead to biases in your encryption implementation which in turn is likely to lead to security weaknesses. Refer to section 2.1.2 of [https://tools.ietf.org/html/rfc2631 RFC 2631] for an example of this in practice.

← Older revision	Revision as of 14:49, 1 April 2013
(No difference)

← Older revision		Revision as of 22:04, 31 March 2013
Line 1:		Line 1:
−	Key derivation is the process of deriving a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key derivation function such as Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH). Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.	+	Key derivation is the process of deriving a shared secret between two peers. So, for example, if Alice and Bob wish to communicate then Alice can calculate the shared secret using her private key and Bob's public key using an appropriate key derivation function such as [[Diffie Hellman\|Diffie-Hellman (DH)]] or [[Elliptic Curve Diffie Hellman\|Elliptic Curve Diffie-Hellman (ECDH)]]. Similarly Bob can calculate the same shared secret using his own private key, and Alice's public key. This shared secret can then be used as the basis for a key for some symmetric encryption algorithm.

	The following code sample is from the OpenSSL manual and shows how a private/public key pair (stored in the variable pkey), and a public key of some peer (stored in the variable peerkey) can be combined to derive the shared secret (stored in the variable skey, with a length stored in skeylen). Obviously equivalent code would be executed on the peer side to come up with the same shared secret.		The following code sample is from the OpenSSL manual and shows how a private/public key pair (stored in the variable pkey), and a public key of some peer (stored in the variable peerkey) can be combined to derive the shared secret (stored in the variable skey, with a length stored in skeylen). Obviously equivalent code would be executed on the peer side to come up with the same shared secret.

← Older revision		Revision as of 17:14, 24 March 2013
Line 46:		Line 46:
	* [[Libcrypto API]]		* [[Libcrypto API]]
	* [[Diffie Hellman]]		* [[Diffie Hellman]]
		+
		+	[[Category:Crypto API]]
		+	[[Category:Examples]]
		+	[[Category:C level]]

← Older revision		Revision as of 22:25, 22 March 2013
Line 45:		Line 45:
	* [[EVP]]		* [[EVP]]
	* [[Libcrypto API]]		* [[Libcrypto API]]
		+	* [[Diffie Hellman]]