delta/go-git.git/src/crypto/tls, branch master github.com: golang/go crypto/tls: fix PSK binder calculation 2023-04-24T13:35:52+00:00 Tero Saarni tero.saarni@gmail.com 2023-04-12T10:07:07+00:00 2c70690451f1484607a9172a4c24f78ae832dcb0 When server and client have mismatch in curve preference, the server will send HelloRetryRequest during TLSv1.3 PSK resumption. There was a bug introduced by Go1.19.6 or later and Go1.20.1 or later, that makes the client calculate the PSK binder hash incorrectly. Server will reject the TLS handshake by sending alert: invalid PSK binder. Fixes #59424 Change-Id: I2ca8948474275740a36d991c057b62a13392dbb9 GitHub-Last-Rev: 1aad9bcf27f563449c1a7ed6d0dd1d247cc65713 GitHub-Pull-Request: golang/go#59425 Reviewed-on: https://go-review.googlesource.com/c/go/+/481955 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> 
When server and client have mismatch in curve preference, the server will
send HelloRetryRequest during TLSv1.3 PSK resumption. There was a bug
introduced by Go1.19.6 or later and Go1.20.1 or later, that makes the client
calculate the PSK binder hash incorrectly. Server will reject the TLS
handshake by sending alert: invalid PSK binder.

Fixes #59424

Change-Id: I2ca8948474275740a36d991c057b62a13392dbb9
GitHub-Last-Rev: 1aad9bcf27f563449c1a7ed6d0dd1d247cc65713
GitHub-Pull-Request: golang/go#59425
Reviewed-on: https://go-review.googlesource.com/c/go/+/481955
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
crypto/tls: retry DialWithTimeout until the listener accepts a connection 2023-04-19T21:40:36+00:00 Bryan C. Mills bcmills@google.com 2023-04-17T14:56:09+00:00 5c865c78c378548c282b22d96e6d0375079d4417 The point of DialWithTimeout seems to be to test what happens when the connection times out during handshake. However, the test wasn't actually verifying that the connection made it into the handshake at all. That would not only fail to test the intended behavior, but also leak the Accept goroutine until arbitrarily later, at which point it may call t.Error after the test t is already done. Instead, we now: - retry the test with a longer timeout if we didn't accept a connection, and - wait for the Accept goroutine to actually complete when the test finishes. Fixes #59646. Change-Id: Ie56ce3297e2c183c02e67b8f6b26a71e50964558 Reviewed-on: https://go-review.googlesource.com/c/go/+/485115 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Commit-Queue: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> 
The point of DialWithTimeout seems to be to test what happens when the
connection times out during handshake. However, the test wasn't
actually verifying that the connection made it into the handshake at
all. That would not only fail to test the intended behavior, but also
leak the Accept goroutine until arbitrarily later, at which point it
may call t.Error after the test t is already done.

Instead, we now:

- retry the test with a longer timeout if we didn't accept a
  connection, and

- wait for the Accept goroutine to actually complete when the test
  finishes.

Fixes #59646.

Change-Id: Ie56ce3297e2c183c02e67b8f6b26a71e50964558
Reviewed-on: https://go-review.googlesource.com/c/go/+/485115
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
all: fix misuses of "a" vs "an" 2023-04-04T14:20:53+00:00 cui fliter imcusg@gmail.com 2023-03-30T16:00:19+00:00 d8d22664c65b0054fc9ea6ba7e945481348fc8fc Fixes the misuse of "a" vs "an", according to English grammatical expectations and using https://www.a-or-an.com/ Change-Id: I53ac724070e3ff3d33c304483fe72c023c7cda47 Reviewed-on: https://go-review.googlesource.com/c/go/+/480536 Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> 
Fixes the misuse of "a" vs "an", according to English grammatical
expectations and using https://www.a-or-an.com/

Change-Id: I53ac724070e3ff3d33c304483fe72c023c7cda47
Reviewed-on: https://go-review.googlesource.com/c/go/+/480536
Run-TryBot: shuang cui <imcusg@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
crypto/tls: replace all usages of BytesOrPanic 2023-02-14T16:52:30+00:00 Roland Shoemaker roland@golang.org 2022-12-14T17:43:16+00:00 66c58b946beaa38de35241c3f64ec358f5ad03f1 Message marshalling makes use of BytesOrPanic a lot, under the assumption that it will never panic. This assumption was incorrect, and specifically crafted handshakes could trigger panics. Rather than just surgically replacing the usages of BytesOrPanic in paths that could panic, replace all usages of it with proper error returns in case there are other ways of triggering panics which we didn't find. In one specific case, the tree routed by expandLabel, we replace the usage of BytesOrPanic, but retain a panic. This function already explicitly panicked elsewhere, and returning an error from it becomes rather painful because it requires changing a large number of APIs. The marshalling is unlikely to ever panic, as the inputs are all either fixed length, or already limited to the sizes required. If it were to panic, it'd likely only be during development. A close inspection shows no paths for a user to cause a panic currently. This patches ends up being rather large, since it requires routing errors back through functions which previously had no error returns. Where possible I've tried to use helpers that reduce the verbosity of frequently repeated stanzas, and to make the diffs as minimal as possible. Thanks to Marten Seemann for reporting this issue. Fixes #58001 Fixes CVE-2022-41724 Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436 Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468125 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com> 
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.

In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.

This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.

Thanks to Marten Seemann for reporting this issue.

Fixes #58001
Fixes CVE-2022-41724

Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
all: fix problematic comments 2023-01-30T18:10:36+00:00 cui fliter imcusg@gmail.com 2023-01-29T06:40:22+00:00 dbfdc446fe70a3639ba00eb3d9141ba10783d7cf Change-Id: If092ae7c72b66f172ae32fa6c7294a7ac250362e Reviewed-on: https://go-review.googlesource.com/c/go/+/463995 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> 
Change-Id: If092ae7c72b66f172ae32fa6c7294a7ac250362e
Reviewed-on: https://go-review.googlesource.com/c/go/+/463995
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
crypto/tls: improve client auth failure alerts 2023-01-20T16:19:42+00:00 Anit Gandhi agandhi@digitalocean.com 2022-11-21T17:17:44+00:00 62a994837a57a7d0c58bb364b580a389488446c9 This change makes it easier for clients to debug mutual TLS connection failures. Currently, there are a few situations where invalid client auth leads to a generic "bad certificate" alert. 3 specific situations have a more appropriate TLS alert code, based on the alert descriptions in the appendix of both RFC5246 and RFC8446. 1. The server is configured to require client auth, but no client cert was provided; the appropriate alert is "certificate required". This applies only to TLS 1.3, which first defined the certificate_required alert code. 2. The client provided a cert that was signed by an authority that is not in the server's trusted set of CAs; the appropriate alert is "unknown certificate authority". 3. The client provided an expired (or not yet valid) cert; the appropriate alert is "expired certificate". Otherwise, we still fall back to "bad certificate". Fixes #52113 Change-Id: I7d5860fe911cad8a1615f16bfe488a37e936dc36 GitHub-Last-Rev: 34eeab587b38549b2ba4a778f7f9894e9b715b43 GitHub-Pull-Request: golang/go#53251 Reviewed-on: https://go-review.googlesource.com/c/go/+/410496 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> 
This change makes it easier for clients to debug mutual TLS connection failures. Currently, there are a few situations where invalid client auth leads to a generic "bad certificate" alert. 3 specific situations have a more appropriate TLS alert code, based on the alert descriptions in the appendix of both RFC5246 and RFC8446.
  1. The server is configured to require client auth, but no client cert was provided; the appropriate alert is "certificate required". This applies only to TLS 1.3, which first defined the certificate_required alert code.
  2. The client provided a cert that was signed by an authority that is not in the server's trusted set of CAs; the appropriate alert is "unknown certificate authority".
  3. The client provided an expired (or not yet valid) cert; the appropriate alert is "expired certificate".
Otherwise, we still fall back to "bad certificate".

Fixes #52113

Change-Id: I7d5860fe911cad8a1615f16bfe488a37e936dc36
GitHub-Last-Rev: 34eeab587b38549b2ba4a778f7f9894e9b715b43
GitHub-Pull-Request: golang/go#53251
Reviewed-on: https://go-review.googlesource.com/c/go/+/410496
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
crypto/tls: fix typo in cacheEntry godoc 2023-01-05T19:33:00+00:00 Tobias Klauser tklauser@distanz.ch 2023-01-05T16:08:07+00:00 119f679a3bd2e60cfc990920f82fd1a5cb006f4c Change-Id: Idcea184a5b0c205efd3c91c60b5d954424f37679 Reviewed-on: https://go-review.googlesource.com/c/go/+/460540 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> 
Change-Id: Idcea184a5b0c205efd3c91c60b5d954424f37679
Reviewed-on: https://go-review.googlesource.com/c/go/+/460540
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
crypto/ecdsa: use bigmod and nistec instead of math/big and crypto/elliptic 2022-11-21T16:19:34+00:00 Filippo Valsorda filippo@golang.org 2022-11-14T17:43:43+00:00 08f2091ce0817346458d2ae984ccea77817cd516 Ignoring custom curves, this makes the whole package constant-time. There is a slight loss in performance for P-384 and P-521 because bigmod is slower than math/big (but P-256 has an assembly scalar field inversion, so doesn't use bigmod for anything big). name old time/op new time/op delta Sign/P256-8 19.2µs ± 2% 19.1µs ± 2% ~ (p=0.268 n=9+10) Sign/P384-8 166µs ± 3% 188µs ± 2% +13.52% (p=0.000 n=10+10) Sign/P521-8 337µs ± 2% 359µs ± 2% +6.46% (p=0.000 n=10+10) Verify/P256-8 58.1µs ± 2% 58.1µs ± 2% ~ (p=0.971 n=10+10) Verify/P384-8 484µs ± 2% 569µs ±12% +17.65% (p=0.000 n=10+10) Verify/P521-8 1.03ms ± 4% 1.14ms ± 2% +11.02% (p=0.000 n=10+10) GenerateKey/P256-8 12.4µs ±12% 12.0µs ± 2% ~ (p=0.063 n=10+10) GenerateKey/P384-8 129µs ±18% 119µs ± 2% ~ (p=0.190 n=10+10) GenerateKey/P521-8 241µs ± 2% 240µs ± 2% ~ (p=0.436 n=10+10) name old alloc/op new alloc/op delta Sign/P256-8 3.08kB ± 0% 2.47kB ± 0% -19.77% (p=0.000 n=10+10) Sign/P384-8 6.16kB ± 0% 2.64kB ± 0% -57.16% (p=0.000 n=10+10) Sign/P521-8 7.87kB ± 0% 3.01kB ± 0% -61.80% (p=0.000 n=10+10) Verify/P256-8 1.29kB ± 1% 0.48kB ± 0% -62.69% (p=0.000 n=10+10) Verify/P384-8 2.49kB ± 1% 0.64kB ± 0% -74.25% (p=0.000 n=10+10) Verify/P521-8 3.31kB ± 0% 0.96kB ± 0% -71.02% (p=0.000 n=7+10) GenerateKey/P256-8 720B ± 0% 920B ± 0% +27.78% (p=0.000 n=10+10) GenerateKey/P384-8 921B ± 0% 1120B ± 0% +21.61% (p=0.000 n=9+10) GenerateKey/P521-8 1.30kB ± 0% 1.44kB ± 0% +10.45% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Sign/P256-8 45.0 ± 0% 33.0 ± 0% -26.67% (p=0.000 n=10+10) Sign/P384-8 69.0 ± 0% 34.0 ± 0% -50.72% (p=0.000 n=10+10) Sign/P521-8 71.0 ± 0% 35.0 ± 0% -50.70% (p=0.000 n=10+10) Verify/P256-8 23.0 ± 0% 10.0 ± 0% -56.52% (p=0.000 n=10+10) Verify/P384-8 43.0 ± 0% 14.0 ± 0% -67.44% (p=0.000 n=10+10) Verify/P521-8 45.0 ± 0% 14.0 ± 0% -68.89% (p=0.000 n=7+10) GenerateKey/P256-8 13.0 ± 0% 14.0 ± 0% +7.69% (p=0.000 n=10+10) GenerateKey/P384-8 16.0 ± 0% 17.0 ± 0% +6.25% (p=0.000 n=10+10) GenerateKey/P521-8 16.5 ± 3% 17.0 ± 0% +3.03% (p=0.033 n=10+10) Change-Id: I4e074ef039b0f7ffbc436a4cdbe4ef90c647018d Reviewed-on: https://go-review.googlesource.com/c/go/+/353849 Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> 
Ignoring custom curves, this makes the whole package constant-time.
There is a slight loss in performance for P-384 and P-521 because bigmod
is slower than math/big (but P-256 has an assembly scalar field
inversion, so doesn't use bigmod for anything big).

name                old time/op    new time/op    delta
Sign/P256-8           19.2µs ± 2%    19.1µs ± 2%     ~     (p=0.268 n=9+10)
Sign/P384-8            166µs ± 3%     188µs ± 2%  +13.52%  (p=0.000 n=10+10)
Sign/P521-8            337µs ± 2%     359µs ± 2%   +6.46%  (p=0.000 n=10+10)
Verify/P256-8         58.1µs ± 2%    58.1µs ± 2%     ~     (p=0.971 n=10+10)
Verify/P384-8          484µs ± 2%     569µs ±12%  +17.65%  (p=0.000 n=10+10)
Verify/P521-8         1.03ms ± 4%    1.14ms ± 2%  +11.02%  (p=0.000 n=10+10)
GenerateKey/P256-8    12.4µs ±12%    12.0µs ± 2%     ~     (p=0.063 n=10+10)
GenerateKey/P384-8     129µs ±18%     119µs ± 2%     ~     (p=0.190 n=10+10)
GenerateKey/P521-8     241µs ± 2%     240µs ± 2%     ~     (p=0.436 n=10+10)

name                old alloc/op   new alloc/op   delta
Sign/P256-8           3.08kB ± 0%    2.47kB ± 0%  -19.77%  (p=0.000 n=10+10)
Sign/P384-8           6.16kB ± 0%    2.64kB ± 0%  -57.16%  (p=0.000 n=10+10)
Sign/P521-8           7.87kB ± 0%    3.01kB ± 0%  -61.80%  (p=0.000 n=10+10)
Verify/P256-8         1.29kB ± 1%    0.48kB ± 0%  -62.69%  (p=0.000 n=10+10)
Verify/P384-8         2.49kB ± 1%    0.64kB ± 0%  -74.25%  (p=0.000 n=10+10)
Verify/P521-8         3.31kB ± 0%    0.96kB ± 0%  -71.02%  (p=0.000 n=7+10)
GenerateKey/P256-8      720B ± 0%      920B ± 0%  +27.78%  (p=0.000 n=10+10)
GenerateKey/P384-8      921B ± 0%     1120B ± 0%  +21.61%  (p=0.000 n=9+10)
GenerateKey/P521-8    1.30kB ± 0%    1.44kB ± 0%  +10.45%  (p=0.000 n=10+10)

name                old allocs/op  new allocs/op  delta
Sign/P256-8             45.0 ± 0%      33.0 ± 0%  -26.67%  (p=0.000 n=10+10)
Sign/P384-8             69.0 ± 0%      34.0 ± 0%  -50.72%  (p=0.000 n=10+10)
Sign/P521-8             71.0 ± 0%      35.0 ± 0%  -50.70%  (p=0.000 n=10+10)
Verify/P256-8           23.0 ± 0%      10.0 ± 0%  -56.52%  (p=0.000 n=10+10)
Verify/P384-8           43.0 ± 0%      14.0 ± 0%  -67.44%  (p=0.000 n=10+10)
Verify/P521-8           45.0 ± 0%      14.0 ± 0%  -68.89%  (p=0.000 n=7+10)
GenerateKey/P256-8      13.0 ± 0%      14.0 ± 0%   +7.69%  (p=0.000 n=10+10)
GenerateKey/P384-8      16.0 ± 0%      17.0 ± 0%   +6.25%  (p=0.000 n=10+10)
GenerateKey/P521-8      16.5 ± 3%      17.0 ± 0%   +3.03%  (p=0.033 n=10+10)

Change-Id: I4e074ef039b0f7ffbc436a4cdbe4ef90c647018d
Reviewed-on: https://go-review.googlesource.com/c/go/+/353849
Auto-Submit: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
crypto/tls: add CertificateVerificationError to tls handshake 2022-11-18T18:50:57+00:00 Gabor Tanz gabor.tanz@swisscom.com 2022-11-18T07:59:03+00:00 f64c2a2ce5dc859315047184e310879dcf747d53 Fixes #48152 Change-Id: I503f088edeb5574fd5eb5905bff7c3c23b2bc8fc GitHub-Last-Rev: 2b0e982f3f6bca33062b0bbd64ed1804801e2c13 GitHub-Pull-Request: golang/go#56686 Reviewed-on: https://go-review.googlesource.com/c/go/+/449336 Run-TryBot: Roland Shoemaker <roland@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> 
Fixes #48152

Change-Id: I503f088edeb5574fd5eb5905bff7c3c23b2bc8fc
GitHub-Last-Rev: 2b0e982f3f6bca33062b0bbd64ed1804801e2c13
GitHub-Pull-Request: golang/go#56686
Reviewed-on: https://go-review.googlesource.com/c/go/+/449336
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
crypto/ecdh: move ECDH method to PrivateKey 2022-11-16T14:37:29+00:00 Filippo Valsorda filippo@golang.org 2022-11-14T11:13:46+00:00 dafc9152047d14d511b37cdd8770324a90c43969 Fixes #56052 Change-Id: Icacba0ed0f77519bca2140c8af68407af97f9734 Reviewed-on: https://go-review.googlesource.com/c/go/+/450335 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Joedian Reid <joedian@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> 
Fixes #56052

Change-Id: Icacba0ed0f77519bca2140c8af68407af97f9734
Reviewed-on: https://go-review.googlesource.com/c/go/+/450335
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joedian Reid <joedian@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>