Why is ECDH implemented but not exposed as a package?

<p>Exactly what the title says. The Go standard library clearly implements ECDH in order to support a number of different TLS cipher suites, but this implementation is not exposed in the standard library, or at least nowhere I am aware of.</p> <p>Is there a reason why this implementation was not exposed? I&#39;m interested in any information relevant to ECDH and Go.</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p><a href="https://golang.org/pkg/crypto/elliptic/">it is</a>. </p></pre>Aeaex: <pre><p>That is the elliptic package. Very aware of it&#39;s existence, thanks! It doesn&#39;t, however, implement DH. It contains what you need to implement it <strong>yourself</strong>, but that isn&#39;t what I was asking. Should have made that more clear.</p></pre>TheMerovius: <pre><p>I genuinely don&#39;t know what you mean. Because to me, it seems that this is at best a question of naming. You can <a href="https://godoc.org/crypto/elliptic#GenerateKey" rel="nofollow">generate a key</a>. And calculate the shared secret from your private and their public key by calling <a href="https://godoc.org/crypto/elliptic#Curve.ScalarMult" rel="nofollow">Curve.ScalarMult</a>. Those two function calls are ECDH.</p> <p>There are crypto protocols on top of ECDH, to deal with key derivation and that specify when to generate new, ephemeral keys, for example (as if you use it in TLS). If you need one of those, it would be helpful if you ask for the specific protocol.</p></pre>Aeaex: <pre><p>Consider the ECDSA package. Everything required to implement ECDSA is contained in the package you linked. However, the ECDSA package exists and contains convenience methods that allow simple and intentional interaction.</p> <p>This doesn&#39;t exist for ECDH. An understanding of ECDH is required to implement it, and you&#39;ve outlined yourself how trivial it is, once you have this understanding, to generate and use the keys. But eliminating the understanding part would be easy with an actual ECDH package. It would also avoid people implementing it wrong and using insecure code in production.</p> <p>So, let&#39;s says my question is: Why not provide a package for this algorithm that addresses potential pitfalls in understanding and implementing the algorithm yourself, like was done for ECDSA?</p></pre>TheMerovius: <pre><p>Perhaps it would be helpful if you could explain what you are trying to do or intend to use this for. It seems to me, that Diffie-Hellman (regardless of the underlying group) only makes sense in the context of a larger crypto-protocol, that specifies where the keys are coming from and what to do with the shared secret - like TLS. I don&#39;t understand what a (EC)DH package would even mean; it&#39;s not a specified protocol on its own.</p></pre>Aeaex: <pre><p>I&#39;m not trying to accomplish anything, this is for the sake of understanding a design choice. ECDH isn&#39;t a protocol, no, but it is a defined algorithm. I&#39;m not sure if our conversation will be all that constructive for either of us. If I&#39;m still not making myself clear to you, it might be best to ditch the communication effort :)</p></pre>i_regret_most_of_it: <pre><p>I agree with <a href="/u/TheMerovius">/u/TheMerovius</a> .</p> <p>The implementation of ECDH in the Go standard library is specific to TLS and its behavior is specific to the TLS. It can&#39;t easily be applied to a different protocol.</p> <p>There is also the implementation of ECDH in the x/crypto/ssh library: <a href="https://github.com/golang/crypto/blob/e8f229864d71a49e5fdc4a9a134c5f85c4c33d64/ssh/kex.go#L210-L377">https://github.com/golang/crypto/blob/e8f229864d71a49e5fdc4a9a134c5f85c4c33d64/ssh/kex.go#L210-L377</a></p> <p>Also an very vaguely related usage of ECDH in x/crypto/openpgp (encryption, not key exchange).</p> <p>The only common thing between them really is using curves, or in the case of key exchange, ScalarMult. Everything else is defined by the standard underlying the protocol.</p> <p>It&#39;s hard to imagine what a common library to the above 3 protocols would even look like, what its applicability would be.</p></pre>reverent_wright: <pre><p>I suppose this is the answer OP was looking for.</p></pre>ESBDB: <pre><p>the bigger question is why go doesn&#39;t implement any Koblitz curves so that we can use secp256k1 for example.</p></pre>JonNRb: <pre><p>This. It makes sense though when you consider that the elliptic package really only exists to implement crypto/tls and related. </p></pre>