Let's Encrypt is defaulting to a longer cross-signed chain on May 4th,
2021 but will offer the ability to download the shorter chain via an
alternate URL via a link header [1]. The shorter chain can be selected
to workaround a validation bug in legacy versions of OpenSSL, GnuTLS,
and LibreSSL. The alternate relation is described in section 7.4.2 of
RFC 8555.
ListCertAlternates should be passed the original certificate chain URL
and will return a list of alternate chain URLs that can be passed to
FetchCert to download.
Fixesgolang/go#42437
[1] https://community.letsencrypt.org/t/production-chain-changes/150739
Change-Id: Iaa32e49cb1322ac79ac1a5b4b7980d5401f4b86e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/277294
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When methods that use POSTs are called on a acme.Client which has a
nil Key field it will cause a deadlock due to an infinite loop in
the code that looks up the account KID. This change adds a check for
the key being nil, and errors out if that is the case. Also adds a
test for this behavior.
Fixesgolang/go#38790
Change-Id: I65ff6bbbade7ed2d85306895904a976089730bbf
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/233164
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This imports the crypto/ed25519/internal/edwards25519/field package from
CL 276272, and uses it in x/crypto/curve25519.
The ScalarMult code was ported 1:1 from curve25519_generic.go.
old code lines new code lines
Go 896 463
Assembly (manually written) 1772 (1772) 362 (34)
43% performance loss on amd64, 33% loss on 386, and 45% gain on arm64.
Feels worth it to remove 1700 lines of manually written assembly.
Apple M1
name old time/op new time/op delta
X25519Basepoint-8 85.0µs ± 1% 46.4µs ± 0% -45.39% (p=0.000 n=10+9)
X25519-8 84.4µs ± 0% 46.7µs ± 2% -44.76% (p=0.000 n=8+9)
Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
name old time/op new time/op delta
X25519Basepoint-4 42.6µs ± 1% 60.9µs ± 1% +43.22% (p=0.000 n=9+10)
X25519-4 42.5µs ± 1% 60.9µs ± 0% +43.17% (p=0.000 n=9+9)
Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz [GOARCH=386]
name old time/op new time/op delta
X25519Basepoint-4 530µs ± 1% 703µs ± 1% +32.81% (p=0.000 n=10+10)
X25519-4 530µs ± 1% 706µs ± 1% +33.18% (p=0.000 n=10+10)
Change-Id: I1dc62a6a3a3e417a1366ff873c475087a0395124
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/315269
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
This change was produced using 'go mod tidy -go=1.17'
with a go command built at CL 315210.
This activates lazy loading, and updates the go.mod file to maintain
the lazy-loading invariants (namely, including an explicit requirement
for every package transitively imported by the main module).
Note that this does *not* prevent users with earlier go versions from
successfully building packages from this module.
For golang/go#36460.
Change-Id: I28a6f54b1e41e9e18b726cacba25a52069b8a4e9
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/316109
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Add support for RFC 8555 subproblems. The type naming is real bike-shed
territory, but I think I've mostly matched the existing style of the
package. In a similar vein the format of how to print subproblems
when stringing an acme.Error is up for debate (it could just be
completely ignored, and require clients to inspect Error.Subproblems
themselves).
Fixesgolang/go#38978
Change-Id: Ice803079bab621ae9410de79e7e75e11c1af21b6
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/233165
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
There is some implicit R0 == $0 here which may not be desired.
"CMP $0, Rx" translates to "cmpd r0, rX" which is less preferred
than "cmpdi r0, 0". Likewise, "ADDE $0, Rx" also turns into
"adde R0, Rx, Rx" which can be simplified to a similar instruction
which adds to zero with carry, "ADDZE Rx, Rx".
Change-Id: I5de17ff5b02c7c9d57daf014c7fe9420bfbeeeab
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/311372
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
HMAC-SHA256 is a perfectly fine MAC algorithm, and there is no need to
ask the user to choose one.
This does break compatibility with the previous API, but it had been
live only for a weekend, so hopefully still in a window in which we can
make changes with a limited blast radius.
Updates golang/go#41430
Change-Id: I03741a545b25b9fcc147760cd20e9d7029844a6c
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/279453
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: James Kasten <jdkasten@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The ability to trigger the 'gssapi-with-mic' authentication method is
not properly gated by the presence of the GSSAPIWithMICConfig field of
the ServerConfig type. If this field is not set and a client sends a
'gssapi-with-mic' request, regardless of if the server advertises it,
the server will panic.
This issue was discovered and reported by Joern Schneewesiz, GitLab
Security Research Team.
Fixes CVE-2020-29652
Change-Id: Ie25de2766e442c8ab46680aae3ac89b0823cdeed
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/278852
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This change clarifies the behaviors of ParseResponse and ParseResponseForCert,
particularly when parsing responses that contain multiple certificate statuses.
Fixesgolang/go#30651
Change-Id: Ia632c8c2a69d1b0c17d71f9f9dcb59ddb0be401b
GitHub-Last-Rev: 481f613438c91521fd90078cc0915cf01cf44b4e
GitHub-Pull-Request: golang/crypto#122
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/220353
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
The existing implementation validates that the prime returned by the server is, in fact, prime, which is extremely slow, especially for large key sizes.
As other implementations, including OpenSSH, do not verify the primality of the provided parameters, this change removes that check.
Fixesgolang/go#41151
Change-Id: I7539714c690f08b5792a0c540cbf46c3e81f13ba
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/252337
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
By using a slice instead of a map for tried authentication methods the order is always the same. Small slices are also faster than maps.
Before the change sometimes I get the error:
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
and sometimes:
ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain
Change-Id: I06507d57e9eef497ff05bce088d52607e69dde3e
GitHub-Last-Rev: 3a46aae4c6e3e5f52ca4b04384b3cc4efc039aa6
GitHub-Pull-Request: golang/crypto#142
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/239171
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Required updating wycheproofModVer to pull the most recent test
vectors. Tests against SHA1, SHA224, SHA256, SHA384, and SHA512
constructions but not the SHA3 variants.
Change-Id: I5b66632ac0c7106bd9b405f6636922a6383d8b9e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/234718
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
rfc4254 section 5.4 states that channel request messages sent to an
unrecognized channel should be replied with a `SSH_MSG_CHANNEL_FAILURE`,
rather than erring out and closing the mux. This can occur with servers
like openssh-portable, which can begin to close a channel and also use
that channel for keepalives before it has received a closed response
from the client.
Fixesgolang/go#38908
Change-Id: Id68b77e16b2889d3a21d505ed8018f9f457e067a
GitHub-Last-Rev: 8a92f87dc30697d9e3805af695efdf1b1dc8409b
GitHub-Pull-Request: golang/crypto#136
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/232659
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Fix for problem with ReadASN1Boolean, which uses invalid tag (Integer / 0x02) when trying to read boolean value. This is a fix for the one case mentioned in "x/crypto/cryptobyte: cannot read boolean values #26565"
This is specified in ITU-T X.690, section 8.2, with DER additions specified in 11.1.
Change-Id: I3c9406bd6febb6112f380224fec1d42a6cd64ed4
GitHub-Last-Rev: fd7d01c897d8aa32d92115be9017f84d75fc4467
GitHub-Pull-Request: golang/crypto#137
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/233161
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>