Elliptic-curve Diffie–Hellman: Difference between revisions
Content deleted Content added
m Reverted edits by 175.100.11.235 (talk) to last version by TwoTwoHello |
No edit summary Tags: Reverted Visual edit Mobile edit Mobile web edit |
||
| Line 1: | Line 1: | ||
'''Elliptic-curve Diffie–Hellman''' ('''ECDH''') is a [[key agreement]] protocol that allows two parties, each having an [[Elliptic curve|elliptic-curve]] public–private key pair, to establish a [[shared secret]] over an [[insecure channel]].<ref>NIST, [http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography], March, 2006.</ref><ref>Certicom Research, [http://www.secg.org/sec1-v2.pdf Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography], Version 2.0, May 21, 2009.</ref><ref>NSA Suite B Cryptography, [http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf Suite B Implementers' Guide to NIST SP 800-56A] {{Webarchive|url=https://web.archive.org/web/20160306033416/http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf |date=2016-03-06 }}, July 28, 2009.</ref> This shared secret may be directly used as a key, or to [[Key derivation function|derive another key]]. The key, or the derived key, can then be used to encrypt subsequent communications using a [[Symmetric-key algorithm|symmetric-key cipher]]. It is a variant of the [[Diffie–Hellman key exchange|Diffie–Hellman]] protocol using [[elliptic-curve cryptography]]. |
'''Elliptic-curve Diffie–Hellman''' ('''ECDH''') is a [[key agreement]] protocol that allows two parties, each having an [[Elliptic curve|elliptic-curve]] public–private key pair, to establish a [[shared secret]] over an [[insecure channel]].<ref>NIST, [http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography], March, 2006.</ref><ref>Certicom Research, [http://www.secg.org/sec1-v2.pdf Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography], Version 2.0, May 21, 2009.</ref><ref>NSA Suite B Cryptography, [http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf Suite B Implementers' Guide to NIST SP 800-56A] {{Webarchive|url=https://web.archive.org/web/20160306033416/http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf |date=2016-03-06 }}, July 28, 2009.</ref> This shared secret may be directly used as a key, or to [[Key derivation function|derive another key]]. The key, or the derived key, can then be used to encrypt subsequent communications using a [[Symmetric-key algorithm|symmetric-key cipher]]. It is a variant of the [[Diffie–Hellman key exchange|Diffie–Hellman]] protocol using [[elliptic-curve cryptography]]. |
||
==.== |
|||
==Key establishment protocol== |
|||
Most standardized protocols based on ECDH derive a symmetric key from <math>x_k</math> using some hash-based key derivation function. |
|||
The following example illustrates how a shared key is established. Suppose [[Alice and Bob|Alice]] wants to establish a shared key with [[Alice and Bob|Bob]], but the only channel available for them may be eavesdropped by a third party. Initially, the [[Elliptic curve cryptography#Domain parameters|domain parameters]] (that is, <math>(p, a, b, G, n, h)</math> in the prime case or <math>(m, f(x), a, b, G, n, h)</math> in the binary case) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key <math>d</math> (a randomly selected integer in the interval <math>[1, n-1]</math>) and a public key represented by a point <math>Q</math> (where <math>Q = d \cdot G</math>, that is, the result of [[Elliptic curve point multiplication|adding]] <math>G</math> to itself <math>d</math> times). Let Alice's key pair be <math>(d_\text{A}, Q_\text{A})</math> and Bob's key pair be <math>(d_\text{B}, Q_\text{B})</math>. Each party must know the other party's public key prior to execution of the protocol. |
|||
The shared secret calculated by bothprivate keys should validate the other public key, and should apply a secure to the raw Diffie–Hellman shared secret to avoid leaking information, s. |
|||
Alice computes point <math>(x_k, y_k) = d_\text{A} \cdot Q_\text{B}</math>. Bob computes point <math>(x_k, y_k) = d_\text{B} \cdot Q_\text{A}</math>. The shared secret is <math>x_k</math> (the ''x'' coordinate of the point). Most standardized protocols based on ECDH derive a symmetric key from <math>x_k</math> using some hash-based key derivation function. |
|||
If Alice maliciously chooses invalid curve points fo |
|||
The shared secret calculated by both parties is equal, because <math>d_\text{A} \cdot Q_\text{B} = d_\text{A} \cdot d_\text{B} \cdot G = d_\text{B} \cdot d_\text{A} \cdot G = d_\text{B} \cdot Q_\text{A}</math>. |
|||
| ⚫ | |||
The only information about her key that Alice initially exposes is her public key. So, no party including Alice can determine Alice's private key (Alice of course knows it by having selected it), unless that party can solve the elliptic curve [[discrete logarithm]] problem. Bob's private key is similarly secure. No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve [[Diffie–Hellman problem]]. |
|||
The public keys are either static (and trusted, say via a certificate) or ephemeral (also known as '''ECDHE''', where final 'E' stands for "ephemeral"). [[Ephemeral key|Ephemeral keys]] are temporary and not necessarily authenticated, so if authentication is desired, authenticity assurances must be obtained by other means. Authentication is necessary to avoid [[man-in-the-middle attack|man-in-the-middle attacks]]. If one of either Alice's or Bob's public keys is static, then man-in-the-middle attacks are thwarted. Static public keys provide neither [[forward secrecy]] nor key-compromise impersonation resilience, among other advanced security properties. Holders of static private keys should validate the other public key, and should apply a secure [[key derivation function]] to the raw Diffie–Hellman shared secret to avoid leaking information about the static private key. For schemes with other security properties, see [[MQV]]. |
|||
If Alice maliciously chooses invalid curve points for her key and Bob does not validate that Alice's points are part of the selected group, she can collect enough residues of Bob's key to derive his private key. Several [[Transport Layer Security|TLS]] libraries were found to be vulnerable to this attack.<ref>{{cite journal |
|||
| url = https://www.ei.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/09/14/main-full.pdf |
|||
| title = Practical Invalid Curve Attacks on TLS-ECDH |
|||
| author1 = Tibor Jager |
|||
| author2 = Jorg Schwenk |
|||
| author3 = Juraj Somorovsky |
|||
| date = 2015-09-04 |
|||
| journal = European Symposium on Research in Computer Security (ESORICS'15) |
|||
}}</ref> |
|||
| ⚫ | |||
== Software == |
== Software == |
||
Revision as of 21:25, 17 February 2022
Elliptic-curve Diffie–Hellman (ECDH) is a key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure channel.[1][2][3] This shared secret may be directly used as a key, or to derive another key. The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher. It is a variant of the Diffie–Hellman protocol using elliptic-curve cryptography.
.
Most standardized protocols based on ECDH derive a symmetric key from using some hash-based key derivation function.
The shared secret calculated by bothprivate keys should validate the other public key, and should apply a secure to the raw Diffie–Hellman shared secret to avoid leaking information, s.
If Alice maliciously chooses invalid curve points fo
While the shared secret may be used directly as a key, it can be desirable
Software
- Curve25519 is a popular set of elliptic curve parameters and reference implementation by Daniel J. Bernstein in C. Bindings and alternative implementations are also available.
- LINE messenger app has used the ECDH protocol for its "Letter Sealing" end-to-end encryption of all messages sent through said app since October 2015.[4]
- Signal Protocol uses ECDH to obtain post-compromise security. Implementations of this protocol are found in Signal, WhatsApp, Facebook Messenger and Skype.
See also
References
- ^ NIST, Special Publication 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, March, 2006.
- ^ Certicom Research, Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0, May 21, 2009.
- ^ NSA Suite B Cryptography, Suite B Implementers' Guide to NIST SP 800-56A Archived 2016-03-06 at the Wayback Machine, July 28, 2009.
- ^ JI (13 October 2015). "New generation of safe messaging: "Letter Sealing"". LINE Engineers' Blog. LINE Corporation. Retrieved 5 February 2018.
