iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Elliptic-curve Diffie–Hellman (ECDH) lets two parties derive the same shared secret without sending their private values to each other. It is a key-agreement method—not encryption or authentication by itself.
How does ECDH produce the same shared secret?
Each participant starts with a private number, called a scalar, and a common public point on an elliptic curve. The curve and its parameters must be agreed in advance.
-
Alice keeps private scalar a secret and calculates public point A = aG, where G is the common base point.
Free tools Windows power users keep installed
One-click scans. No signup required.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Bob keeps private scalar b secret and calculates public point B = bG.
#1 Best Overall
-
They exchange public points A and B.
-
Alice multiplies Bob’s public point by her private scalar: aB = abG. Bob multiplies Alice’s public point by his private scalar: bA = abG.
Both computations produce the same result, while the private scalars stay with their owners. An observer can see the exchanged public points, but recovering a private scalar from its public point is intended to be computationally infeasible under the scheme’s security assumptions. NIST describes elliptic-curve Diffie–Hellman as a key-establishment scheme based on the discrete-logarithm problem.
What does ECDH do—and what does it not do?
ECDH establishes shared secret material. A protocol typically feeds that material into a key-derivation function (KDF) to produce keys with the required length and context. Deriving keying material is a distinct step covered by NIST SP 800-56C Rev. 2.
Recommended Free Tools
ECDH alone does not encrypt messages or prove who the other participant is. Without authentication supplied by the surrounding protocol, an active attacker could intervene between the parties and establish separate secrets with each of them. Protocols therefore need appropriate peer authentication; transcript binding and key confirmation may also be required by their design.
Which curves and standards are relevant?
Curve25519 and Curve448
RFC 7748, an Internet Research Task Force informational RFC published in January 2016, specifies Curve25519 and Curve448 for Diffie–Hellman use. It describes approximate security levels of 128 bits for Curve25519 and 224 bits for Curve448. These are the RFC’s design-level descriptions, not a guarantee about every implementation or its surrounding protocol.
The RFC says the curves were intended to support constant-time implementations and scalar multiplication resistant to a wide range of side-channel attacks, including timing and cache attacks. Practical protection still depends on the implementation and protocol.
NIST recommendations
NIST SP 800-56A Rev. 3, published in April 2018, specifies discrete-logarithm-based key-establishment schemes over finite fields and elliptic curves, including Diffie–Hellman and MQV variants. NIST’s publication page records a January 6, 2026 planning note that the publication will be updated.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →NIST SP 800-56C Rev. 2, published in August 2020, addresses deriving keying material from shared secrets produced by schemes covered by SP 800-56A or SP 800-56B. Its page records a January 6, 2026 planning note that it will be revised. For compliance-sensitive work, check the current revision and the applicable profile rather than assuming these editions remain final.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should an implementation or protocol account for?
-
Private-value generation: Generate private scalars securely and keep them secret. Weak randomness can undermine the exchange; follow the requirements and parameter rules for the scheme in use.
-
Curve and encoding agreement: Use the curve, public-value encoding, and protocol required for interoperability or compliance. Different curves and encodings are not interchangeable.
-
Peer inputs: Process received public values and shared outputs according to the selected curve and protocol specification, including its rules for invalid or low-order inputs.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Key derivation: Apply a suitable KDF to produce keys of the required length and bind them to the relevant context.
Best Value
-
Authentication: Ensure the protocol authenticates peers as required. The ECDH calculation itself does not do this.
-
Side channels: Consider timing, cache, and other implementation leaks; choosing a curve does not by itself guarantee a secure implementation.
Quick Recap
SaleBestseller No. 3SaleBestseller No. 4
Sources
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
