Repository navigation
Merge golang/crypto master, replacing our ACME profiles patch with upstream's - #10
Open
wallrj-cyberark wants to merge 77 commits into
Open
wallrj-cyberark wants to merge 77 commits into
wallrj-cyberark wants to merge 77 commits into
Conversation
A malicious server can crash any client by sending a truncated exit-status payload, which triggers a panic in binary.BigEndian.Uint32. Change-Id: Iff4fe182b40210c99d46562f6c3b5ecf38bb98b4 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/780181 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: David Chase <drchase@google.com>
serverAuthenticate only bounded real failures via MaxAuthTries.
PartialSuccessError responses and the publickey isQuery short-circuit
both kept the loop running without incrementing authFailures, so a
client could keep the server processing SSH_MSG_USERAUTH_REQUEST
messages indefinitely on a single connection.
Add an unconditional cap, maxAuthServerAttempts = 128, on the total
number of userauth requests handled per connection. The counter is
incremented at the top of the loop before method dispatch, so every
method and every isQuery / partial-success path counts. When the cap
is exceeded the server sends SSH_MSG_DISCONNECT with reason 2 ("too
many authentication attempts"), mirroring the MaxAuthTries handling.
The bound is well below OpenSSH's hard cap of 1024 but above any
realistic multi-step auth flow.
Change-Id: I56779fc55cd00ddfd32ec938f8de3a49be0145dc
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/781903
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The drain loop added in 3c7c869 ("ssh: fix deadlock on unexpected channel responses") receives from ch.msg without checking the comma-ok flag. Once ch.msg is closed by channel.close(), receives succeed immediately with the zero value, so the default arm is never taken and the loop spins forever, pinning a CPU core for every concurrent SendRequest caller on a torn-down channel. Use the comma-ok idiom to detect the closed channel and break out. Fixes golang/go#79658 Change-Id: Id80aa5d8429550c7a68e8759aed9ffba3aabb006 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/783680 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Neal Patel <neal@golang.org> Auto-Submit: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Neal Patel <nealpatel@google.com>
The drain loop added in 4e7a738 ("ssh: fix deadlock on unexpected global responses") receives from m.globalResponses without checking the comma-ok flag. Once mux.loop closes globalResponses on connection teardown, the loop spins forever on the zero value, pinning a CPU core for every concurrent SendRequest caller. Use the comma-ok idiom to detect the closed channel and break out. Change-Id: Icf0a7419fe5b206b7a4f70429fa9f25d0b5af731 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/783681 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <nealpatel@google.com> Auto-Submit: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Neal Patel <neal@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com>
parseOpenSSHPrivateKey builds an rsa.PrivateKey directly from the unmarshalled OpenSSH key blob, bypassing parseRSA and its modulus limit. Validate() and Precompute() then perform several modular exponentiations whose cost grows with the size of the prime factors; in particular Precompute() recomputes the CRT coefficient as q^(p-2) mod p, which is cubic in |p|. A maliciously crafted key with oversized N and P can keep the CPU busy for hours or days during a single load. Mirror the parseRSA validation here: cap the modulus at 8192 bits (the same limit enforced by crypto/tls), reject exponents larger than 24 bits, and reject invalid exponent values (< 3 or even). In addition, bound each prime factor at 4096 bits to prevent the CRT computation from becoming the dominant cost. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: Ia5991f25dd41a22eddd7cf63a8fc5106de9e9663 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782420 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
parseRSAKey and parseRSACert build an rsa.PrivateKey directly from the Add request body and then call priv.Precompute(). The CRT coefficient recomputation in Precompute() is cubic in the size of the prime factors, so accepting RSA keys with arbitrary modulus and prime sizes can consume excessive CPU resources during a single Add operation. Add a checkRSAKeyParams helper that enforces the same bounds as parseRSA in the ssh package (modulus <= 8192 bits, exponent <= 24 bits, exponent >= 3 and odd) plus a cap of 4096 bits on each prime factor, and call it from both parseRSAKey and parseRSACert before priv.Precompute(). The previous inline check on the exponent (BitLen > 30) is subsumed by the new helper, which tightens it to BitLen > 24 for consistency with parseRSA. Change-Id: I6f0bbbfdc1db13d62a1f85e1d0e6ae517f000443 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782421 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
passphraseProtectedOpenSSHKey decodes the bcrypt round count from the key file and passes it directly to bcrypt_pbkdf.Key, whose running time is linear in that count. Files specifying very large round values cause the decryption to consume excessive CPU time: a uint32 maximum is several months of work on commodity hardware. Cap the accepted round count at 2048 (128x the default of 16, a few seconds of CPU on a modern core). OpenSSH itself does not impose an upper bound, but accepting arbitrary values turns key loading into a resource-exhaustion footgun for any code that processes files supplied by end users. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: I01112bdf1b484ae4fab5dc8841d1a272f112df74 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782422 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
insertKey and insertCert assume an ed25519.PrivateKey is exactly 64 bytes long: a 32-byte seed followed by a 32-byte public key. The expression []byte(k)[32:] panics with "slice bounds out of range" when a shorter slice is passed, which is reachable through the exported Add API and crashes the caller process. Reject ed25519 keys whose length is not ed25519.PrivateKeySize in all four branches (value and pointer variants of insertKey and insertCert), using the same error wording already used by parseEd25519Cert in server.go. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: I4a053835588aad4c3482fe1ca8045542cd960500 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782423 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Previously, the server selected the Diffie-Hellman group based solely on the MaxBits value provided by the client. This resulted in suboptimal modulus selection, often ignoring the client's PreferredBits or selecting a larger-than-necessary group. This change implements a "best fit" selection algorithm similar to OpenSSH's choose_dh logic. It attempts to find the smallest available group larger than or equal to the client's PreferredBits, falling back to the largest available group within the accepted range if no group above the preference is available. Additionally, this commit caches the parsed Oakley groups using sync.OnceValue, avoiding repeated big.Int parsing on every handshake while keeping the cost out of package initialization. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: Idfa81bbcf354a7fb7b541cb4bbeb6e4a0181398a Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782424 Auto-Submit: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Previously, parseECDSA determined the curve purely based on the key blob content, ignoring the algorithm identifier passed to parsePubKey. This allowed a mismatch where a key could be encoded with an algorithm type of "ecdsa-sha2-nistp256" but contain a NIST P-384 or P-521 curve. The parser would succeed, returning a key with a type different from the one indicated by the caller/wire format. This change updates parseECDSA to accept the expected algorithm type and verify that it matches the curve specified in the key data. This matches the behavior of OpenSSH's ssh_ecdsa_deserialize_public in ssh-ecdsa.c, which rejects a curve identifier that does not correspond to the key algorithm name. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: I9c748be948cca65e2f41089bb7510466d3bb316a Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782425 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
The previous implementation used bytes.TrimSpace, which strips all Unicode whitespace categories (e.g., non-breaking spaces). However, OpenSSH's known_hosts parser (hostfile.c) strictly treats only ASCII space (0x20) and horizontal tab (0x09) as separators. This discrepancy meant the Go parser might interpret fields differently than OpenSSH, potentially treating parts of a key or hostname as separators if they contained Unicode whitespace. This change replaces bytes.TrimSpace with a local trimSpace helper that only trims " \t", ensuring parsing behavior consistent with the reference implementation. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: Ia536889636de2c167d2507c01e3f1b7c033c9a8f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782426 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
The parseLine function previously ignored the key type field (e.g., "ssh-rsa") in known_hosts entries, relying solely on the type information embedded within the base64-encoded key blob. OpenSSH's sshkey_read implementation explicitly verifies that the key type declared in the text matches the type of the parsed key, returning SSH_ERR_KEY_TYPE_MISMATCH if they differ. This change adds a check to ensure the declared key type matches key.Type(), returning an error for malformed lines where they diverge. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: Id4f35c74055f5691088273630b50cdd02c81bfe9 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782427 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Previously, parseLine would accept lines with multiple markers (e.g., "@cert-authority @Revoked ...") or unknown markers (e.g., "@unknown ..."). In these cases, the second or unknown marker was incorrectly parsed as the hostname. This often resulted in confusing downstream errors (like "illegal base64 data") because field positions were shifted. OpenSSH's hostfile.c strictly enforces a limit of one marker per line and validates that markers must be exactly "@cert-authority" or "@Revoked". This change adds a check to ensure that the parsed hostname does not start with '@'. This effectively catches both multiple markers (where the second marker becomes the host) and unknown markers (which are not consumed as markers and thus become the host), enforcing strict compliance with the OpenSSH format. This issue was found during a security audit by NCC Group Cryptography Services, sponsored by Teleport, and was assessed and is being fixed as a non-security bug. Change-Id: I13bb04d1f2610483ad9c6d1020e5100b6feded90 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/782428 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Pass -F none and -o IdentityAgent=none to ssh(1) invocations in the
CLI tests. Without these flags, a user's ~/.ssh/config can enable
Control{Master,Persist}, which causes the ssh process to fork a
background daemon that holds stdout/stderr pipes open, preventing
CombinedOutput from ever returning. The agent flag prevents keys loaded
in the user's SSH agent from being offered to the server before the test
key, which would exhaust MaxAuthTries and cause a disconnect.
Fixes golang/go#79411
Change-Id: Id5b073e6df661006183d000928d7ef6e6096b933
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/777900
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Make the runtime gssapi-with-mic guard match the existing configuration and method advertisement checks. An incomplete GSSAPIWithMICConfig can be treated as unavailable when building the advertised auth method list, while still remaining reachable from the runtime auth dispatcher. Treat incomplete configurations as not configured. This change introduces a single internal completeness check for GSSAPIWithMICConfig and uses it for the startup authentication validation, the runtime gssapi-with-mic dispatch guard, and the advertised authentication method list. The change also adds a regression test. The test configures a server with a normal PasswordCallback, a GSSAPIWithMICConfig with Server set, and AllowLogin intentionally unset. It then uses a custom client auth method that explicitly sends a USERAUTH_REQUEST with Method set to gssapi-with-mic even though the server does not advertise that method, and verifies that authentication fails cleanly with "ssh: gssapi-with-mic auth not configured". No golang/go issue reference is available yet. Change-Id: I9a0c965d3a56192bd68309aa41e2c1f91952036c GitHub-Last-Rev: 0267bda GitHub-Pull-Request: golang#345 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/773460 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The PKCS#12 PBKDF iteration count is read directly from the input file with no upper bound. A crafted 83-byte .p12 file can set iterations to 2^31-1 (2147483647), causing Decode() to block a CPU core permanently. This change adds a maximum iteration limit of 1000000 in both verifyMac and pbDecrypterFor. Any file that specifies more iterations than this cap is rejected with an error. For reference, OpenSSL caps PBKDF2 at 10000000 iterations, and scrypt is bounded by its memory-hardness parameters. The 1000000 limit is generous for legitimate PKCS#12 files while still preventing denial of service. Fixes golang/go#78524 Change-Id: I1d12d6f5d90e347ca0dc113678abc51b0cff8d85 GitHub-Last-Rev: a0370d4 GitHub-Pull-Request: golang#343 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/759900 Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: I1dc78ceffd32c80457b284aa1bcefb6dfc2757ba Reviewed-on: https://go-review.googlesource.com/c/crypto/+/788222 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Equivalent coverage using newer Wycheproof vectors has been added to the standard library, alongside the implementations under test. In the case where the algorithm doesn't exist in the stdlib, but is intended to be supported there one day (e.g. chacha20poly1305) we flip the relationship and run the Wycheproof tests from the stdlib on the vendored /x/crypto. As a result the legacy Wycheproof coverage in this repo can be removed. Change-Id: Ic07d559e42599b715906f5bcc39be10944a8dde4 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/758420 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org>
This is an automated CL which updates the NSS root bundle. [git-generate] go generate ./x509roots Change-Id: I448f9962a67bf042b04a2e34f16ae02a004d6edd Reviewed-on: https://go-review.googlesource.com/c/crypto/+/791040 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Update the IDKey example to use RFC 9106's first recommended Argon2id option and clarify the relationship between the first and second recommended options. Fixes golang/go#79823 Change-Id: If44a86a5a8112b02fab97b4d5e325fe91d6049ee GitHub-Last-Rev: a764ae6 GitHub-Pull-Request: golang#357 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/789020 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Previously Manager.createCert() read state.locked without holding any lock, while the owner goroutine wrote state.locked = false under the state's write lock. Concurrent goroutines for the same domain raced on that field. We fix the issue by removing the certState.locked field and instead having Manager.certState() return an additional owner bool computed under the m.stateMu lock. This allows the Manager.createCert() caller to know whether it must block on the read lock and return the state handled by another goroutine, or instead do the work itself and release the write lock. A regression unit test is included that fails under -race without the fix, and passes with the fix in-place. Fixes golang/go#80119 Change-Id: I0f4c5c98f7e6bcf1ab71a3c0707bb0c7ce73415b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/793840 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
ForwardToAgent and ForwardToRemote only read the main stream of the auth-agent@openssh.com channels they accept. If a peer sends data on the channel's extended (stderr) stream the bytes accumulate in the client-side extPending buffer and the receive window is never replenished, because the window is only adjusted as a side effect of ReadExtended. That can pin up to channelWindowSize (2 MiB) of memory per channel and silently stalls any stderr traffic once the window is exhausted. The auth-agent protocol does not use stderr, so a well-behaved peer never sends anything on it. To stay tolerant of misbehaving peers without leaving the channel half-stuck, drain the stderr stream into io.Discard, mirroring the existing DiscardRequests pattern. The goroutine exits when the channel is closed because Stderr().Read returns io.EOF. Add a regression test that opens an agent-forwarding channel and writes more than the default window on the stderr stream from the server side. Without the fix the write blocks once the remote window is exhausted; with the fix the bytes are drained and the agent stream remains usable. Change-Id: Iadf8ea6ca726c058421bbc39f92e0100579fda17 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/783720 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
A malicious peer can send control characters and escape sequences in SSH_MSG_DISCONNECT; strip these characters and %q escape it. Change-Id: I266f78630a7a816a79ce4dda568ce57d7c3f6fb0 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/780180 Commit-Queue: Nicola Murino <nicola.murino@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Nicola Murino <nicola.murino@gmail.com>
The parseDSAKey function constructed a *dsa.PrivateKey directly from the add-identity request without validating the key parameters. Unlike DSA certificates, whose parameters are checked by the ssh package when the certificate's public key is parsed, raw DSA keys added to the agent were not validated at all. Align the raw DSA key parsing with the validation already performed by the main ssh package. Fixes golang/go#79725 Change-Id: I537cc2175d35c19848c90c68739cf94ba7b50e10 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/795422 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
ParseAuthorizedKey and ParseKnownHosts previously ignored the key type field (e.g. "ssh-rsa") in each entry, relying solely on the type information embedded within the base64-encoded key blob. For ParseAuthorizedKey this also caused a single-token option to be silently dropped: a line such as "restrict <key>" (with the key type omitted) was parsed as an unrestricted key, because the option token landed in the key type position and was discarded together with its meaning. The same happens for no-pty, no-port-forwarding and the other single-word options. OpenSSH's sshkey_read rejects such lines outright, as the option token cannot be read as a key type. OpenSSH's sshkey_read also explicitly verifies that the key type declared in the text matches the type of the parsed key, returning SSH_ERR_KEY_TYPE_MISMATCH if they differ. This change adds, in both functions, a check that the declared key type matches the decoded key's type, returning an error for malformed lines where they diverge. This mirrors the fix already applied to the ssh/knownhosts package in CL 782427. Change-Id: I9163108d964de4be8a415fe0efd68e6b71f77990 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/792840 Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Nicola Murino <nicola.murino@gmail.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
The package is unmaintained, unsafe at any speed, and does not receive security fixes. Document that, and point at the ProtonMail fork for those that _must_ still use OpenPGP. Change-Id: Ia602eaaf9e08bd25389400ebe7f346b60bdb9d99 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/794200 Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: I431b878ec8830bf1894ae19176b5984b00954557 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/798280 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org>
ParseRequest was documented as erroring for inputs that contained an optional request signature, and as only supporting requests for a single certificate. However, prior to this commit DER inputs that contained a signature succeeded without verifying the signature, and inputs that contained multiple certificate identifiers succeeded but only the first certificate identifier was unmarshalled. This commit updates the function behaviour to return an error for the signature case as described in the docs, and to clarify the documentation for inputs with multiple certificate identifiers. Fixes golang/go#80300 Change-Id: I7446422d6c98bd406b8c43e55fea9a16ace9d4a6 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/798220 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-by: Nicholas Husin <husin@google.com>
channel.close closes the internal Go channels (msg, incomingRequests); calling it twice panics with "close of closed channel". Both current callers run on the mux loop and are serialized, so the panic is not reachable today. Harden close by guarding it with sync.Once, so that the connection does not become fragile to any future bug that reaches close twice. Change-Id: I5d8d948367538ea5561724033c4ee4daa668e221 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/797060 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
newChannel published the channel into the mux's chanList (via chanList.add) before assigning its localId, and openChannel/Accept set maxIncomingPayload only after newChannel returned. For an outbound channel, whose newChannel runs on an application goroutine, the mux loop could observe the channel through getChan before those fields were initialized, reading a zero localId or maxIncomingPayload with no happens-before relationship. Assign localId inside add while the chanList lock is held, and set maxIncomingPayload (always channelMaxPacket) in newChannel itself, so a channel returned by getChan is always fully initialized. Change-Id: Ib54a5d10dcb5c1ad8ed4dabe5d8d2790778be298 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/797061 Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Revocation matching compared full marshaled key blobs, so a @Revoked line containing a plain host key did not revoke a certificate certifying that key: when the server presented such a certificate, IsRevoked only matched the whole certificate blob or the CA key, and verification succeeded even though the underlying host key was revoked. OpenSSH's check_key_not_revoked compares keys with sshkey_equal_public, which considers only the public portions and explicitly allows comparisons between certificates and plain keys. Match that behavior by normalizing both @Revoked entries and lookups to the underlying public key: for a certificate, the certified key rather than the certificate blob. This also makes a @Revoked line containing a certificate revoke the plain key it certifies Change-Id: I3029d59e68fb01f2340763e2eae25cac23c6193d Reviewed-on: https://go-review.googlesource.com/c/crypto/+/816841 Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is an automated CL which updates the NSS root bundle. [git-generate] go generate ./x509roots Change-Id: I3be04cd4cb6e44856beaa074fdb62a58ff8ce35b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/820300 Auto-Submit: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
This gradual step towards removing/inlining subjectsEqual can happen after Go 1.27.0 is released and the bundle starts being generated with it. Change-Id: Ib315bae69c45922c3f0aac5d2c0155fb5d94229f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/775782 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
CertChecker.CheckCert ignored source-address on the assumption that serverAuthenticate would enforce it, but that only happens in the server-side user authentication path. Nothing enforced it in the host key path, so CheckHostKey accepted CA-signed host certificates carrying source-address regardless of the server's address, and the same applied to applications calling CheckCert directly. Drop the special case: every critical option must be listed in SupportedCriticalOptions, host and user certificates alike. Authenticate, the only path where serverAuthenticate does enforce source-address, checks against a copy of the CertChecker with that option appended. Fixes golang/go#80872 Change-Id: I3c3554b71ea2a4ce4b17696a9596b973b7d74b00 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/816840 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Nicola Murino <nicola.murino@gmail.com>
A channel in the mux's chanList is not usable until it is established: an outbound channel has no confirmed remote id until the peer's open confirmation, and an inbound channel is not serviced by the application until it is accepted. handlePacket processed any channel message on it, so a misbehaving peer could flood channel requests and block the mux read loop on the send to incomingRequests, deadlocking the connection, or close an outbound channel before confirming it, making the victim tear down a half-initialized channel and emit a close for remote id 0, an unrelated channel of the peer. No such packet can be legitimate: the peer learns an inbound channel's local id only from the confirmation we have not sent yet, and on an outbound channel RFC 4254 lets it answer the open request only with a confirmation or a failure. Add an established flag, set when the channel becomes usable: for an outbound channel when the open response is received, for an inbound channel by Accept before the confirmation is sent. Until then handlePacket drops every packet other than the open response. The flag is separate from decided, which Reject also sets: a rejected channel is decided but must never carry traffic. Fixes CVE-2026-78662 Fixes golang/go#81316 Change-Id: Ib0983bb216a49808a2db1f4a4d92ee9fe38a3c51 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/826504 Auto-Submit: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com>
ch.msg is only read while the channel open or a channel request with a reply is pending, so anything the default arm of channel.handlePacket delivered to it was never consumed. The blocking send there let a misbehaving peer fill the buffer with well-formed but unexpected message types carrying a valid channel id and stall the mux read loop, deadlocking the whole connection. No conforming peer sends such messages during the connection protocol. Treat them as a protocol error and tear the connection down, as handleUnknownChannelPacket already does for the same messages when the channel id is not in use. Fixes CVE-2026-56855 Fixes golang/go#81317 Change-Id: I87420dfe68fcb62a17df4b47dc5ffb6ccd72ba26 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/826524 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: I39f495ef42016b2ab0c91f54b792ac16b967006f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/829324 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
This is an automated CL which updates the NSS root bundle. [git-generate] go generate ./x509roots Change-Id: I975f934aabe6eaf6b9f256db2b6942c45c9bd7b4 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/833664 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When an order finalization response is not immediately valid, Client.CreateOrderCert depends on the ACME server returning a Location header. The header value is used as the URL for polling the updated order status. RFC 8555 does not require this header, so CreateOrderCert does not interoperate with ACME servers that omit it (e.g. Pebble v2.9.0+). This commit adds Client.CreateCertFromOrder, which accepts an *Order and uses its URI for polling instead of relying on the finalization response's Location header. It also updates existing callers and documentation to use the new method and updates the integration tests to Pebble v2.10.1 (the latest available version), which omits the finalization Location header. Fixes golang/go#77704 Change-Id: I0852f19c5d18d6debc9c9686fa2c14a2e39663c2 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/817000 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Benchmark results on Loongson-3C6000 @ 2.20GHz:
goos: linux
goarch: loong64
pkg: golang.org/x/crypto/argon2
cpu: Loongson-3C6000/S @ 2200.00MHz
| old.bench | new.bench |
| sec/op | sec/op vs base |
Argon2i/_Time:_3_Memory:_32_MB,_Threads:_1 123.36m ± 0% 76.67m ± 0% -37.85% (p=0.000 n=10)
Argon2i/_Time:_4_Memory:_32_MB,_Threads:_1 163.7m ± 0% 101.3m ± 0% -38.09% (p=0.000 n=10)
Argon2i/_Time:_5_Memory:_32_MB,_Threads:_1 195.0m ± 0% 116.5m ± 8% -40.24% (p=0.000 n=10)
Argon2i/_Time:_3_Memory:_64_MB,_Threads:_4 259.4m ± 0% 165.3m ± 0% -36.28% (p=0.000 n=10)
Argon2i/_Time:_4_Memory:_64_MB,_Threads:_4 349.9m ± 0% 220.8m ± 0% -36.92% (p=0.000 n=10)
Argon2i/_Time:_5_Memory:_64_MB,_Threads:_4 437.6m ± 0% 276.0m ± 0% -36.92% (p=0.000 n=10)
Argon2d/_Time:_3,_Memory:_32_MB,_Threads:_1 116.34m ± 0% 72.07m ± 0% -38.06% (p=0.000 n=10)
Argon2d/_Time:_4,_Memory:_32_MB,_Threads:_1 154.42m ± 0% 95.28m ± 0% -38.30% (p=0.000 n=10)
Argon2d/_Time:_5,_Memory:_32_MB,_Threads:_1 192.4m ± 0% 115.9m ± 2% -39.73% (p=0.000 n=10)
Argon2d/_Time:_3,_Memory:_64_MB,_Threads:_4 254.4m ± 0% 165.2m ± 0% -35.06% (p=0.000 n=10)
Argon2d/_Time:_4,_Memory:_64_MB,_Threads:_4 345.5m ± 1% 221.0m ± 0% -36.04% (p=0.000 n=10)
Argon2d/_Time:_5,_Memory:_64_MB,_Threads:_4 432.1m ± 0% 276.2m ± 0% -36.09% (p=0.000 n=10)
Argon2id/_Time:_3,_Memory:_32_MB,_Threads:_1 116.49m ± 0% 72.38m ± 0% -37.86% (p=0.000 n=10)
Argon2id/_Time:_4,_Memory:_32_MB,_Threads:_1 154.59m ± 0% 95.71m ± 3% -38.09% (p=0.000 n=10)
Argon2id/_Time:_5,_Memory:_32_MB,_Threads:_1 192.5m ± 0% 115.0m ± 0% -40.25% (p=0.000 n=10)
Argon2id/_Time:_3,_Memory:_64_MB,_Threads:_4 255.6m ± 0% 165.7m ± 0% -35.18% (p=0.000 n=10)
Argon2id/_Time:_4,_Memory:_64_MB,_Threads:_4 345.4m ± 0% 221.5m ± 0% -35.87% (p=0.000 n=10)
Argon2id/_Time:_5,_Memory:_64_MB,_Threads:_4 431.9m ± 0% 276.6m ± 0% -35.96% (p=0.000 n=10)
geomean 227.7m 142.6m -37.40%
| old.bench | new.bench |
| B/op | B/op vs base |
Argon2i/_Time:_3_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_4_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_5_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_3_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_4_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_5_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_3,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_4,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_5,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_3,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_4,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_5,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_3,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_4,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_5,_Memory:_32_MB,_Threads:_1 32.00Mi ± 0% 32.00Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_3,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_4,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_5,_Memory:_64_MB,_Threads:_4 64.01Mi ± 0% 64.01Mi ± 0% ~ (p=1.000 n=10) ¹
geomean 45.26Mi 45.26Mi +0.00%
¹ all samples are equal
| old.bench | new.bench |
| allocs/op | allocs/op vs base |
Argon2i/_Time:_3_Memory:_32_MB,_Threads:_1 31.00 ± 0% 31.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_4_Memory:_32_MB,_Threads:_1 39.00 ± 0% 39.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_5_Memory:_32_MB,_Threads:_1 47.00 ± 0% 47.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_3_Memory:_64_MB,_Threads:_4 73.00 ± 0% 73.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_4_Memory:_64_MB,_Threads:_4 93.00 ± 0% 93.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2i/_Time:_5_Memory:_64_MB,_Threads:_4 113.0 ± 0% 113.0 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_3,_Memory:_32_MB,_Threads:_1 31.00 ± 0% 31.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_4,_Memory:_32_MB,_Threads:_1 39.00 ± 0% 39.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_5,_Memory:_32_MB,_Threads:_1 47.00 ± 0% 47.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_3,_Memory:_64_MB,_Threads:_4 73.00 ± 0% 73.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_4,_Memory:_64_MB,_Threads:_4 93.00 ± 0% 93.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2d/_Time:_5,_Memory:_64_MB,_Threads:_4 113.0 ± 0% 113.0 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_3,_Memory:_32_MB,_Threads:_1 31.00 ± 0% 31.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_4,_Memory:_32_MB,_Threads:_1 39.00 ± 0% 39.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_5,_Memory:_32_MB,_Threads:_1 47.00 ± 0% 47.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_3,_Memory:_64_MB,_Threads:_4 73.00 ± 0% 73.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_4,_Memory:_64_MB,_Threads:_4 93.00 ± 0% 93.00 ± 0% ~ (p=1.000 n=10) ¹
Argon2id/_Time:_5,_Memory:_64_MB,_Threads:_4 113.0 ± 0% 113.0 ± 0% ~ (p=1.000 n=10) ¹
geomean 59.32 59.32 +0.00%
¹ all samples are equal
Change-Id: Ia814057ddfdefbe1d23431fa366189ffe5852b96
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/826304
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add an assembly implementation of ChaCha20 for Loong64 using LSX SIMD
instructions. This significantly improves performance across all message
sizes on LoongArch machines.
Benchmark results on Loongson-3C6000 @ 2.20GHz:
goos: linux
goarch: loong64
pkg: golang.org/x/crypto/chacha20
cpu: Loongson-3C6000/S @ 2200.00MHz
│ old.bench │ new.bench │
│ sec/op │ sec/op vs base │
ChaCha20/64 188.4n ± 0% 156.9n ± 0% -16.72% (p=0.000 n=10)
ChaCha20/256 666.4n ± 0% 151.5n ± 0% -77.27% (p=0.000 n=10)
ChaCha20/10x25 1037.0n ± 0% 578.9n ± 0% -44.18% (p=0.000 n=10)
ChaCha20/4096 10.207µ ± 0% 1.955µ ± 0% -80.85% (p=0.000 n=10)
ChaCha20/100x40 11.856µ ± 0% 5.785µ ± 0% -51.21% (p=0.000 n=10)
ChaCha20/65536 162.99µ ± 0% 31.60µ ± 0% -80.61% (p=0.000 n=10)
ChaCha20/1000x65 165.57µ ± 0% 41.93µ ± 0% -74.67% (p=0.000 n=10)
geomean 6.369µ 2.141µ -66.38%
│ old.bench │ new.bench │
│ B/s │ B/s vs base │
ChaCha20/64 323.9Mi ± 0% 389.0Mi ± 0% +20.10% (p=0.000 n=10)
ChaCha20/256 366.4Mi ± 0% 1611.2Mi ± 0% +339.80% (p=0.000 n=10)
ChaCha20/10x25 229.8Mi ± 0% 411.8Mi ± 0% +79.19% (p=0.000 n=10)
ChaCha20/4096 382.7Mi ± 0% 1998.1Mi ± 0% +422.08% (p=0.000 n=10)
ChaCha20/100x40 321.8Mi ± 0% 659.4Mi ± 0% +104.94% (p=0.000 n=10)
ChaCha20/65536 383.5Mi ± 0% 1977.8Mi ± 0% +415.78% (p=0.000 n=10)
ChaCha20/1000x65 374.4Mi ± 0% 1478.4Mi ± 0% +294.86% (p=0.000 n=10)
geomean 335.9Mi 999.2Mi +197.50%
Change-Id: I6b8d243819d0ab1a1d6540648ed9bd00ecad5a2e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/683196
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Benchmark results on Loongson-3C6000 @ 2.20GHz:
goos: linux
goarch: loong64
pkg: golang.org/x/crypto/blake2b
cpu: Loongson-3C6000/S @ 2200.00MHz
| old.bench | new.bench |
| sec/op | sec/op vs base |
Write128 350.0n ± 0% 178.3n ± 0% -49.06% (p=0.000 n=10)
Write1K 2.687µ ± 0% 1.286µ ± 0% -52.14% (p=0.000 n=10)
Sum128 362.6n ± 0% 183.7n ± 0% -49.34% (p=0.000 n=10)
Sum1K 2.788µ ± 0% 1.295µ ± 0% -53.54% (p=0.000 n=10)
geomean 987.4n 483.3n -51.06%
| old.bench | new.bench |
| B/s | B/s vs base |
Write128 348.8Mi ± 0% 684.8Mi ± 0% +96.31% (p=0.000 n=10)
Write1K 363.5Mi ± 0% 759.6Mi ± 0% +108.99% (p=0.000 n=10)
Sum128 336.6Mi ± 0% 664.4Mi ± 0% +97.37% (p=0.000 n=10)
Sum1K 350.3Mi ± 0% 754.0Mi ± 0% +115.23% (p=0.000 n=10)
geomean 349.7Mi 714.5Mi +104.32%
Change-Id: I181a0284c5913cca34f074466f7d83439554e450
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/659775
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Benchmark results on Loongson-3C6000 @ 2.20GHz:
goos: linux
goarch: loong64
pkg: golang.org/x/crypto/salsa20
cpu: Loongson-3C6000/S @ 2200.00MHz
| old.bench | new.bench |
| sec/op | sec/op vs base |
XOR1K 3835.5n ± 0% 493.9n ± 0% -87.12% (p=0.000 n=10)
| old.bench | new.bench |
| B/s | B/s vs base |
XOR1K 254.6Mi ± 0% 1977.4Mi ± 0% +676.64% (p=0.000 n=10)
Change-Id: I9f795e7f4e2c467ba9a41c9e6f460612536021ba
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/683255
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
ParseKnownHosts split and trimmed the entry with bytes.Fields and bytes.TrimSpace, both of which are Unicode aware, so it disagreed with ssh/knownhosts on where a field ends: since CL 782426 that package trims ASCII space and tab only. OpenSSH's hostkeys_foreach_file and sshkey_read delimit every field with ' ' and '\t' alone, so any other Unicode space character is part of the field. Match that here, in parseAuthorizedKey, which receives the key field from ParseKnownHosts, and in ParseAuthorizedKey, whose line sshd skips with skip_space. Leading whitespace that is not ASCII is no longer trimmed, so an entry starting with a no-break space followed by '#' is now a host pattern rather than a comment, as it is for OpenSSH and for ssh/knownhosts. Change-Id: I942165fb94529dad7179ccb121ea345a5a16c3e1 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/832724 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
ParseKnownHosts rejected an entry holding more than five fields, so a comment longer than two words, or longer than one word behind a marker, was an error, while ssh/knownhosts and OpenSSH both accept it. Change-Id: Ibf8a804a4957d320ac9bd6ebf47c86787a7b0f49 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/832726 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
ParseKnownHosts and ParseAuthorizedKey ended the line at the first carriage return anywhere in it, so an entry whose host name held one lost the rest of the line and was skipped without an error, while ssh/knownhosts read the same entry as a host name holding a carriage return, and registered it. OpenSSH ends the line at the first '\n' and keeps every carriage return, so one inside a field is part of that field. Keep those, and drop a single trailing one, which is what bufio.ScanLines already does for ssh/knownhosts, so that both parsers read a file with CRLF line endings the same way. Change-Id: I9ba8508b02b3272a26b7b074a961956085baca8f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/832727 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The *-etm@openssh.com MAC algorithms require the packet length to be sent unencrypted and the MAC to be computed over the ciphertext. Only streamPacketCipher implemented this, cbcCipher ignored the negotiated mode and always encrypted the length and MAC'd the plaintext, so a CBC cipher combined with an EtM MAC only worked against another Go peer. Fixes golang/go#64779 Change-Id: I110c1bcaaf075d858c70ba87b070f1d5718ecf4c Reviewed-on: https://go-review.googlesource.com/c/crypto/+/552495 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <mark@golang.org>
Implement ssh-mldsa-44, ssh-mldsa-65 and ssh-mldsa-87 from draft-sfluhrer-ssh-mldsa-08, for host keys and public key authentication. The names are registered in the IANA "Public Key Algorithm Names" registry. They require Go 1.27 and come last in the preference lists, so that adding an ML-DSA host key to a server doesn't change the host key its clients already know. The wire format is verified against the ML-DSA-65 test key of PKIX-SSH, the only other implementation of the draft, which uses the same names since its commit e035f40b. Certificates are left out, since no certificate algorithm is defined for ML-DSA keys. ML-DSA keys can still sign certificates. Private key files are left out too: the draft, Section 5, declares the private key format out of scope, and no implementation defines an OpenSSH one. Keys in the PKCS #8 seed-only form are supported through crypto/x509, and are the only portable form: Go writes them, and OpenSSL based implementations read them. Keys written by OpenSSL in its default form, with both seed and expanded key, must be converted to seed-only first. Change-Id: I6915911c60a7e0c155942aefb4c4d76198e0185e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/819920 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com>
Add ssh-mldsa-44-cert-v01@golang.org, ssh-mldsa-65-cert-v01@golang.org and ssh-mldsa-87-cert-v01@golang.org, certifying the keys of the corresponding ML-DSA public key algorithms. No specification defines a certificate algorithm for ML-DSA, hence the vendor names, as per RFC 4251, Section 4.2. The certificate format is that of draft-ietf-sshm-cert-01, with the public key fields holding the key as encoded by draft-sfluhrer-ssh-mldsa-08, Section 4: a single string of fixed length. Like the plain algorithms, they require Go 1.27 and are negotiated by default at the end of the host key preference list. The agent protocol can list, sign with and authenticate with ML-DSA keys and certificates held by a Keyring, since those operations only carry public keys and signatures. Adding them through the protocol is left out, with the private key format of the plain algorithms: no private certificate format is defined. When one is, the private key fields should be the 32-byte seed. Change-Id: Id0b7da49e532e57af2c765f7f2e71141f763d7b4 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/828364 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
The SSH protocol, and the file formats that come with it, are byte oriented. Folding case or trimming space by Unicode rules makes a parser accept an entry that its peers reject, or read a field as ending where they do not, which is how the known_hosts parsers here came to disagree with each other and with OpenSSH. Add a test walking the source of ssh and of the packages under it, and rejecting a call to a strings or bytes function that decides on its own what whitespace or what case is, as net/http does for the same reason. An explicit cutset, as in bytes.Trim(b, " \t"), stays allowed. A doc comment that named one of those functions is reworded, since the test matches comments too. Change-Id: I4482a16632bd50b8dd8fc3f158da6da36ac44f03 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/832728 Auto-Submit: Nicola Murino <nicola.murino@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Let's Encrypt is already supporting Profiles in requests made to the new-order endpoint and returning them in the meta field of the directory. This parses those and adds a new OrderOption to enable specifying this when constructing the new order request via AuthorizeOrder. When profiles are not supported, this returns an error early. When the specified profile name is not in the list of specified profiles, an error is returned early. Fixes golang/go#73101 Co-authored-by: Daniel McCarney <daniel@binaryparadox.net> Change-Id: Idc7d0a6908d970d96a9c2b6097e849be22d9054f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/843885 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Standard Go practice is to use t.Logf() and t.Log() over log.Printf() and log.Print when we have a t handy. This helps keep the output associated with the specific test case. Change-Id: I15148c0430ecc3624aae8e70eced9df2d82b4b8e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/843925 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
When an order finalization response is not immediately valid, Client.CreateOrderCert depends on the ACME server returning a Location header. The header value is used as the URL for polling the updated order status. RFC 8555 does not require this header, so CreateOrderCert does not interoperate with ACME servers that omit it (e.g. Pebble v2.9.0+). This commit adds Client.CreateCertFromOrder, which accepts an *Order and uses its URI for polling instead of relying on the finalization response's Location header. It also updates existing callers and documentation to use the new method and updates the integration tests to Pebble v2.10.1 (the latest available version), which omits the finalization Location header. Fixes golang/go#77704 Change-Id: I0852f19c5d18d6debc9c9686fa2c14a2e39663c2 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/817000 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> (cherry picked from commit b4dcfb5) Signed-off-by: Richard Wall <richard.wall@cyberark.com>
…stream's golang/crypto merged ACME profiles support in 4e01a84 (golang/go#73101). Our own profiles patch (20ccc12) was based on an early version of that change, so this merge takes upstream's implementation and drops ours. The resolved acme/ tree is golang/crypto master plus our two remaining patches, which upstream does not have yet: - 061aeaf: RetryAfter on Authorization, Order and Challenge (proposal golang/go#74454) - fa31f54: ACME Renewal Information, RFC 9773 (proposal golang/go#60958) Everything outside acme/ is identical to golang/crypto master. API changes for callers: - WithOrderProfile(string) is now WithOrderIssuanceProfile(ProfileName). - Directory.Profiles is now map[ProfileName]string, without Has or GetDescription. - ErrCADoesNotSupportProfiles and ErrProfileNotInSetOfSupportedProfiles are unexported upstream. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Richard Wall <richard.wall@cyberark.com>
wallrj-cyberark
force-pushed
the
acme-resync-golang-master
branch
from
October 6, 2026 13:01
5b6c4a5 to
bac6bdb
Compare
|
Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits. 📝 Please follow instructions in the contributing guide to update your commits with the DCO Full details of the Developer Certificate of Origin can be found at developercertificate.org. The list of commits missing DCO signoff:
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This merges golang/crypto master into our fork and replaces our ACME profiles patch with upstream's.
golang/crypto merged ACME profiles support on 5 October in 4e01a84 (golang/go#73101). Our profiles patch, 20ccc12, was based on an early version of that change, so we no longer need it. After this merge, the fork carries only the two patches upstream does not have yet:
RetryAfteron Authorization, Order and Challenge (proposal proposal: x/crypto/acme: add RetryAfter field to the Authorization, Order & Challenge objects golang/go#74454). Open PR feat: refactor challenge controller to be entirely non blocking cert-manager#7805 uses it.We cannot drop the fork until upstream accepts ARI.
This PR is stacked on #9. Please merge #9 first, then this one. Use merge commits for both, not squash or rebase: cert-manager's
third_party/klone.yamlpins commits on these branches.The consuming cert-manager PR is cert-manager/cert-manager#9431.
The
dcocheck needs a maintainer/override dco. The merge brings in golang/crypto commits, which never carry aSigned-off-byline. My own commits are signed off. #7, the previous merge of golang/crypto master, was overridden the same way.API changes for callers
WithOrderProfile(string)becomesWithOrderIssuanceProfile(ProfileName).Directory.Profilesbecomesmap[ProfileName]string, withoutHasorGetDescription.ErrCADoesNotSupportProfilesandErrProfileNotInSetOfSupportedProfilesare unexported upstream.Ordergains upstream'sProfilefield.How the merge was resolved and tested
acme/tree equals golang/crypto master plus 061aeaf and fa31f54, cherry-picked in that order. Everything outsideacme/is identical to golang/crypto master:git diff golang/master bac6bdb -- . ':!acme'is empty.go vet ./acme/...is clean.go test ./acme/...passes, including the ARI tests andTestWithPebbleagainst Pebble v2.10.1.[with Claude]