Update upstream #1
Open
Conversation
This file contains 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
When reading GCM and ChaChaPoly1305 packets, don't make assumptions about the size of the enciphered plaintext. This fixes two panics caused by standards non-compliant malformed packets. Thanks to Rod Hynes, Psiphon Inc. for reporting this issue. Fixes golang/go#49932 Fixes CVE-2021-43565 Change-Id: I660cff39d197e0d04ec44d11d792b22d954df2ef Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1262659 Reviewed-by: Katie Hockman <[email protected]> Reviewed-by: Julie Qiu <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/crypto/+/368814 Trust: Roland Shoemaker <[email protected]> Trust: Katie Hockman <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Julie Qiu <[email protected]> Reviewed-by: Katie Hockman <[email protected]>
This test downloads JSON test files from GitHub. If the network connection flakes, the test may hang indefinitely, and builders with flaky network connections might want to avoid unnecessary downloading anyway. Fixes golang/go#50076 Change-Id: I0655a34fce8a003794290c0c82ae75492eda4429 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/370659 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Katie Hockman <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Fixes golang/go#49678 Change-Id: If8a40e25edd810a66165ab78dd68d9b7fc2699f8 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/365674 Reviewed-by: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> Trust: Alex Rakoczy <[email protected]> Trust: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
…opagates Fixes golang/go#44611 Change-Id: I81b3c3b7be25fe4e492695fa5935e70aa7b96c07 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/378074 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
Use a net.Pipe, rather than setting up a local TCP connection, for testing malformed SSH requests, since we don't need the complex intricacies of a real connection to test this protocol behavior. Fixes golang/go#50161 Change-Id: I5e46c42041ddd03b06725469216b82b801990e64 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/371874 Reviewed-by: Bryan Mills <[email protected]> Trust: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Let's Encrypt is revoking all certificates verified with TLS-ALPN-01 beofre January 26th due to a compliance issue. Detect them and force a renewal. Also, fix the tests which were not testing if expired certificates were renewed anymore, as the test certificates were always invalid due to not having SANs. Change-Id: If9d0632b2edfe0b7fb70f6cfd7e65e46e2d047dc Reviewed-on: https://go-review.googlesource.com/c/crypto/+/381114 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
Change-Id: Ie5520f33674471b4a018feb9d0efaf6696ea38a2 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/381715 Run-TryBot: Filippo Valsorda <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Trust: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Expose the previously private KID field of the Client type. This allows callers which have locally cached their key identity to avoid needing to make a call to the ACME service every time they construct a new client. Fixes golang/go#46303 Change-Id: I219167c5b941f56a2028c4bc253ff56386845549 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/354697 Trust: Katie Hockman <[email protected]> Reviewed-by: Katie Hockman <[email protected]> Trust: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
x/crypto/ed25519 moved to the standard library in Go 1.13. This change drops the compatibility wrapper we were keeping around to make Go 1.12 and earlier work. Change-Id: I860ed963a0660753d01c89014c21360b239a38ac Reviewed-on: https://go-review.googlesource.com/c/crypto/+/317169 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Katie Hockman <[email protected]> Trust: Katie Hockman <[email protected]>
Change-Id: Icd770cee9ce183f75c49c301f96a4aab73e80303 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/381674 Reviewed-by: Ian Lance Taylor <[email protected]> Trust: Cherry Mui <[email protected]>
LetsEncrypt removed it anyway. No API changes. Just a lot of deleted code. Fixes golang/go#46654 Co-authored-by: Brad Fitzpatrick <[email protected]> Change-Id: I65cd0d33236033682b767403ad92aa572bee4fdd Reviewed-on: https://go-review.googlesource.com/c/crypto/+/380314 Trust: Filippo Valsorda <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]> Trust: Brad Fitzpatrick <[email protected]>
Change-Id: I2287ab3492c105791b03f40d45b5dff5a56aa32a GitHub-Last-Rev: 02cdf82 GitHub-Pull-Request: #183 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/319269 Trust: Alberto Donizetti <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
At Let's Encrypt, we've found that most autocert users do not provide an email address, which makes it hard to get in touch when things go wrong with their client. Demonstrating how to provide an email will probably encourage more people to provide one. Change-Id: I0aa1ecea7cfbe55ae155804194fb57a8e695c658 GitHub-Last-Rev: 902b5fe GitHub-Pull-Request: #186 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/323313 Reviewed-by: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Katie Hockman <[email protected]> Trust: Katie Hockman <[email protected]>
Fixes golang/go#50805 Change-Id: Icdd2835b1626240faf61936288f279570c873158 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/381614 Trust: Ian Lance Taylor <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
TestRenewFromCache and TestRenewFromCacheAlreadyRenewed had several races and API misuses: 1. They called t.Fatalf from a goroutine other than the one invoking the Test function, which is explicitly disallowed (see https://pkg.go.dev/testing#T). 2. The test did not stop the renewal timers prior to restoring test-hook functions, and the process of stopping the renewal timers itself did not wait for in-flight calls to complete. That could cause data races if one of the renewals failed and triggered a retry with a short-enough randomized backoff. (One such race was observed in https://build.golang.org/log/1a19e22ad826bedeb5a939c6130f368f9979208a.) 3. The testDidRenewLoop hooks accessed the Manager.renewal field without locking the Mutex guarding that field. 4. TestGetCertificate_failedAttempt set a testDidRemoveState hook, but didn't wait for the timers referring to that hook to complete before restoring it, causing races with other timers. I tried pulling on that thread a bit, but couldn't untangle the numerous untracked goroutines in the package. Instead, I have made a smaller and more local change to copy the value of testDidRemoveState into a local variable in the timer's closure. Given the number of untracked goroutines in this package, it is likely that races and/or deadlocks remain. Notably, so far I have been unable to spot the actual cause of golang/go#51080. For golang/go#51080 Change-Id: I7797f6ac34ef3c272f16ca805251dac3aa7f0009 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/384594 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
If we are going to send the disconnect message and close the connection, because we have exhausted the number of authentication attempts, don't send the final authentication failure message. This behavior matches that of OpenSSH. Fixes golang/go#51149 Change-Id: I43b2de2e854f789161cd7fd6c05876661adfb2c1 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/385236 Trust: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> Auto-Submit: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
For golang/go#51080 Change-Id: Icf4414ab58bdea44b793a66770b4c05f9faf5387 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/385675 Trust: Bryan Mills <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Reviewed-by: Jeremy Faller <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change-Id: I5832916eb921d2d18e3082cd04520e22e2b04127 GitHub-Last-Rev: c0999b8 GitHub-Pull-Request: #207 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/390414 Reviewed-by: Roland Shoemaker <[email protected]> Trust: Carlos Amedee <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
If the server/client cipher chosen is one of the two AEAD ciphers that we support ([email protected] and [email protected]), don't attempt to find a common MAC algorithm in findAgreedAlgorithms. Similarly in newPacketCipher, don't attempt to generate a MAC key if we are using a AEAD cipher. Fixes golang/go#51406 Change-Id: Id48ae72f052cb0a0c597b32e9901a0f218e4161f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/389214 Trust: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]>
Change-Id: I65ac40d86c4f0ee5552cd2e167ac91a735f6c56e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392134 Trust: Brad Fitzpatrick <[email protected]> Run-TryBot: Brad Fitzpatrick <[email protected]> Reviewed-by: David Crawshaw <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Maisem Ali <[email protected]>
RFC 8731 standardized [email protected] as curve25519-sha256, and some systems only advertise support for the new name. Fixes golang/go#48756 Change-Id: Ice35874cd8c07ad48752686ac368bf11ab793f77 Co-authored-by: Filippo Valsorda <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/crypto/+/385394 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> Trust: Matt Layher <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
RFC 9142 made diffie-hellman-group14-sha256 from RFC 8268 a MUST, and it's strictly better than diffie-hellman-group14-sha1, which we already have, and trivial to add. > The method of key exchange used for the name "diffie-hellman- > group14-sha256" is the same as that for "diffie-hellman-group14-sha1" > except that the SHA256 hash algorithm is used. Ignore the bigger groups which have a meaningful performance cost, and don't share the same interoperability benefit. Adapted from CL 387994. Fixes golang/go#31731 Co-authored-by: Nicola Murino <[email protected]> Change-Id: Id4ce345a2065840f193986739ea890f105a1e929 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392014 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
The previous code
if gex.g.Cmp(one) != 1 && gex.g.Cmp(pMinusOne) != -1 {
deobfuscates to the classic mistake
if g <= 1 && g >= p - 1 {
which is never true.
What the code actually intended to do is
if gex.g.Cmp(one) != 1 || gex.g.Cmp(pMinusOne) != -1 {
or more readably and consistently with the diffieHellman method
if gex.g.Cmp(one) <= 0 || gex.g.Cmp(pMinusOne) >= 0 {
Now, is this a security issue? The incorrect checks apply to g and k,
but not what we call Y and the spec calls f. RFC 4419 says:
Either side MUST NOT send or accept e or f values that are not in the
range [1, p-1]. If this condition is violated, the key exchange
fails. To prevent confinement attacks, they MUST accept the shared
secret K only if 1 < K < p - 1.
Note that RFC 8268, Section 4 updates the equivalent RFC 4253 statement
(although not the RFC 4419 one) about e and f, but we are already doing
the correct full check there.
DH Public Key values MUST be checked and both conditions:
1 < e < p-1
1 < f < p-1
MUST be true. Values not within these bounds MUST NOT be sent or
accepted by either side. If either one of these conditions is
violated, then the key exchange fails.
This simple check ensures that:
o The remote peer behaves properly.
o The local system is not forced into the two-element subgroup.
The check on K seems like a proxy for checking a number of ways to fix
the DH output (for example by manipulating g) to one of 0, 1, or -1.
This should not be meaningful to security for two reasons:
- all parameters end up in the "transcript" hash that will get signed
by the server's host key, and if the attacker controls the host
key's signature, they have the ability to MitM without resorting to
confinement attacks
- the client secret is ephemeral, so leaking bits of it by forcing it
into small sub-groups does not gain the attacker anything, as the
secret does not get reused
Indeed, this is the same explanation of why it's ok not to check that p
is indeed a (safe) prime, which even OpenSSH omits. Building an
equivalent attack by manipulating p instead of g is left as an exercise
to the reader.
For the future, this is a case study in why we should not add complexity
even when it looks easy enough to do. CL 174257 added the
diffie-hellman-group-exchange kex. That introduced a data race (arguably
a security issue), which was fixed in CL 222078. Then it was too slow,
which led to CL 252337 that removed the primalty check, which required a
full analysis of whether it's safe to skip it, and checking against
other implementations. Now we find there's a bug and we have to do
another security analysis that not even the RFC bothered to do in order
to decide if it's a security issue. My decision in
golang/go#17230 (comment)
does not look like the right one in hindsight.
While at it, clean up the code some
- drop useless bit size bounds logic in the server stub that get
ignored by the rest of the function
- make p and g local variables instead of method fields, since they
are not persistent state (this was originally a data race which was
fixed in CL 222078 by making Client not a pointer receiver)
Updates golang/go#17230
Change-Id: I4b1c68537109f627ccd75ec381dcfab57ce1768c
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392015
Trust: Filippo Valsorda <[email protected]>
Run-TryBot: Filippo Valsorda <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
RFC 8332, Section 2 sets up two overlapping namespaces: public key formats and public key algorithms. * The formats are what we currently have KeyAlgo constants for, and they appear in PublicKey.Type. * The algorithms are the set of both KeyAlgo and SigAlgo constants, and they appear in Signature.Format (amongst other places). This is incoherent, because that means Signature.Format can be both a KeyAlgo (like KeyAlgoECDSA256) or a SigAlgo (like SigAlgoRSASHA2256). One solution would be to duplicate all the KeyAlgo constants into the SigAlgo namespace, but that would be confusing because applications are currently using KeyAlgos where they'd be supposed to use the new SigAlgos (while we can't deprecate the KeyAlgos because they are still necessary for the PublicKey.Type namespace). Instead, drop the separate namespaces, and use KeyAlgos throughout. There are simply some KeyAlgos that can't be a PublicKey.Type. Take the opportunity to fix the stuttering SHA22565/SHA2512 names. It's totally ok to call those hashes SHA-256 and SHA-512 without the family infix. For golang/go#49952 Change-Id: Ia1fce3912a7e60aa70a88f75ed311be331fd19d5 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392354 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
The server implementation looks at the HostKeys to advertise and
negotiate host key signature algorithms. A fundamental issue of the
Signer and AlgorithmSigner interfaces is that they don't expose the
supported signature algorithms, so really the server has to guess.
Currently, it would guess exclusively based on the PublicKey.Type,
regardless of whether the host key implemented AlgorithmSigner. This
means that a legacy Signer that only supports ssh-rsa still led the
server to negotiate rsa-sha2 algorithms. The server would then fail to
find a suitable host key to make the signature and crash.
This won't happen if only Signers from this package are used, but if a
custom Signer that doesn't support SignWithAlgorithm() but returns
"ssh-rsa" from PublicKey().Type() is used as a HostKey, the server is
vulnerable to DoS.
The only workable rules to determine what to advertise seems to be:
1. a pure Signer will always Sign with the PublicKey.Type
2. an AlgorithmSigner supports all algorithms associated with the
PublicKey.Type
Rule number two means that we can't add new supported algorithms in the
future, which is not great, but it's too late to fix that.
rsaSigner was breaking rule number one, and although it would have been
fine where it's used, I didn't want to break our own interface contract.
It's unclear why we had separate test key entries for rsa-sha2
algorithms, since we can use the ssh-rsa key for those. The only test
that used them, TestCertTypes, seemed broken: the init was actually
failing at making the corresponding signers rsaSigners, and indeed the
test for the SHA-256 signer expected and checked a SHA-512 signature.
Pending CVE
For golang/go#49952
Change-Id: Ie658eefcadd87906e63fc7faae8249376aa96c79
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392355
Trust: Filippo Valsorda <[email protected]>
Run-TryBot: Filippo Valsorda <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
The server side implementation was not actually populating the SSH_MSG_USERAUTH_INFO_REQUEST field with the KeyboardInteractiveChallenge argument, although the client side was deserializing it and passing it to the KeyboardInteractiveChallenge callback. Anyway, the first field of SSH_MSG_USERAUTH_INFO_REQUEST is "name", not "user". Maybe the confusion was due to the first field of SSH_MSG_USERAUTH_REQUEST being the user. RFC 4256, Section 3.3, says this about it One possibility is to use the name field (possibly prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. and examples include "CRYPTOCard Authentication", "Password Authentication", and "Password Expired". Co-authored-by: Kevin Wallace <[email protected]> Change-Id: Ic6ec0dfea2122704603c44f42898a980689a15c9 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/372234 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
CL 220037 had implemented support for host authentication using rsa-sha2-256/512, but not client public key authentication. OpenSSH disabled the SHA-1 based ssh-rsa by default in version 8.8 (after pre-announcing it in versions 8.2, 8.3, 8.4, 8.5, 8.6, and 8.7) although some distributions re-enable it. GitHub will start rejecting ssh-rsa for keys uploaded before November 2, 2021 on March 15, 2022. https://github.blog/2021-09-01-improving-git-protocol-security-github/ The server side already worked, as long as the client selected one of the SHA-2 algorithms, because the signature flowed freely to Verify. There was however nothing verifying that the signature algorithm matched the advertised one. The comment suggested the check was being performed, but it got lost back in CL 86190043. Not a security issue because the signature had to pass the callback's Verify method regardless, and both values were checked to be acceptable. Tested with OpenSSH 8.8 configured with "PubkeyAcceptedKeyTypes -ssh-rsa" and no application-side changes. The Signers returned by ssh/agent (when backed by an agent client) didn't actually implement AlgorithmSigner but ParameterizedSigner, an interface defined in an earlier version of CL 123955. Updates golang/go#49269 Fixes golang/go#39885 For golang/go#49952 Change-Id: I13b41db8041f1112a70f106c55f077b904b12cb8 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392394 Trust: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
The server-sig-algs logic was not working for certificate algorithms.
Follow-up on CL 392394.
Tested with OpenSSH 8.8 configured with
PubkeyAcceptedKeyTypes [email protected]
Updates golang/go#39885
For golang/go#49952
Change-Id: Ic230dd6f98e96b7938acbd0128ab37d33b70abe5
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392974
Trust: Filippo Valsorda <[email protected]>
Run-TryBot: Filippo Valsorda <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
In accordance to RFC8308, send ext-info-c only during the first key exchange. Some server implementations such as OpenSSH 7 will send an extInfoMsg message each time when ext-info-c is received. This results in a closed connection, as our client does not expect this message while handling the mux. See https://bugzilla.mindrot.org/show_bug.cgi?id=2929 regarding the behaviour of OpenSSH if it sees ext-info-c in later key exchanges. Fixes golang/go#51808 Change-Id: Id94f1ef73cec6147136246b0b6048b57db92660d GitHub-Last-Rev: fcfe5ed GitHub-Pull-Request: #208 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/394134 Reviewed-by: Filippo Valsorda <[email protected]> Run-TryBot: Filippo Valsorda <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Trust: Roland Shoemaker <[email protected]>
Fixes golang/go#38340 Change-Id: I77afc901584ac3361eafa13c9ee9f8cf9ec2ee28 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/389256 Trust: Roland Shoemaker <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> Auto-Submit: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]>
The original SSH RFC 4253 explicitly disallows padding. This applies to ssh-rsa signatures. The updated SSH RFC 8332 which defines the SHA2 RSA signature variants explicitly calls out the existence of signers who produce short signatures and specifies that verifiers may allow this behavior. In practice, PuTTY 0.81 and prior versions, as well as SSH.NET prior to 2024.1.0 always generated short signatures. Furthermore, PuTTY is embedded in other software like WinSCP and FileZilla, which are updated on their own schedules as well. This leads to occasional unexplained login errors, when using RSA keys. OpenSSH server allows these short signatures for all RSA algorithms. Fixes golang/go#68286 Change-Id: Ia60ece21bf9c111c490fac0c066443ed5ff7dd29 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/598534 Reviewed-by: Nicola Murino <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Nicola Murino <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: Iae75e5fcbcfe3709820dd66638a763f662f8d939 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/603396 Auto-Submit: Gopher Robot <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: David Chase <[email protected]>
When adding a new key, if we already have a Signer with the same public key, we now replace it with the new one instead of duplicating it. Before this change we had this: $ ssh-add -l 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA) 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA-CERT) $ ssh-add /home/nicola/ssh_certs/id_rsa Identity added: /home/nicola/ssh_certs/id_rsa (nicola@p1) Certificate added: /home/nicola/ssh_certs/id_rsa-cert.pub (myid) $ ssh-add -l 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA) 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA-CERT) 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA) 3072 SHA256:bsBRHC/xgiqBJdSuvSTNpJNLTISP/G356jNMCRYC5Es nicola@p1 (RSA-CERT) Change-Id: Iad1b1a6dc94f68f53f05d7d1172f0017839976fc Reviewed-on: https://go-review.googlesource.com/c/crypto/+/602955 Reviewed-by: Filippo Valsorda <[email protected]> Auto-Submit: Nicola Murino <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
This is an automated CL which updates the NSS root bundle. Change-Id: I95cf0b3e86f1e013d486a0bbd050a8b4bea5d6e9 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/610060 Reviewed-by: Roland Shoemaker <[email protected]> Auto-Submit: Gopher Robot <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="argon2/blamka_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: I3567eb80ef80dff248225f17470122c0a4e6951e
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/600315
Reviewed-by: Filippo Valsorda <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="blake2s/blake2s_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: Ica8bf9f0b42dc93714aa54e783fa74ed19e6b9f4
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/601216
Reviewed-by: Roland Shoemaker <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
Reviewed-by: Filippo Valsorda <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="blake2b/blake2bAVX2_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: Ia2af1b82c871e26b89bd9a2d9fb187cc49e18341
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/600836
Reviewed-by: Filippo Valsorda <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="blake2b/blake2b_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: I6dd59fb0b0365674aa5e43b69a57ea60fbcc4ba1
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/600456
Reviewed-by: Dmitri Shuralyov <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Filippo Valsorda <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE":salsa20/salsa/salsa20_amd64.s) \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
salsa20/salsa/salsa20_amd64.s \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: Ica0bb06f8b074ad566a979d33ddc81d8a38491b1
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/601217
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Filippo Valsorda <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Parameter metadata not found in the reference assembly file has been
added, leading to a diff on the lines where those symbols are
referenced.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="chacha20poly1305/chacha20poly1305_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
155,157c155,157
< MOVQ dst(FP), DI
< MOVQ key+24(FP), R8
< MOVQ src+48(FP), SI
---
> MOVQ dst_base(FP), DI
> MOVQ key_base+24(FP), R8
> MOVQ src_base+48(FP), SI
159c159
< MOVQ ad+72(FP), CX
---
> MOVQ ad_base+72(FP), CX
4684,4686c4684,4686
< MOVQ dst(FP), DI
< MOVQ key+24(FP), R8
< MOVQ src+48(FP), SI
---
> MOVQ dst_base(FP), DI
> MOVQ key_base+24(FP), R8
> MOVQ src_base+48(FP), SI
4688c4688
< MOVQ ad+72(FP), CX
---
> MOVQ ad_base+72(FP), CX
Change-Id: Ia3a8e70b7440944ee739499c41ddceb70e054ef9
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/601442
Reviewed-by: Filippo Valsorda <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="internal/poly1305/sum_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: I80212c95d1b05335d7f6b73a3030b6f812f6105b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/600035
Reviewed-by: Roland Shoemaker <[email protected]>
Reviewed-by: Filippo Valsorda <[email protected]>
Reviewed-by: Dmitri Shuralyov <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: I94bb1c6a4bb08aff8c146e84a9d4b3e353f098c2 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/610638 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Auto-Submit: Gopher Robot <[email protected]>
These were problematic but previously easy to miss. They're now easy to spot thanks to build failures at Go tip as of CL 610736. For golang/go#68796. Change-Id: I167f2cce2376b4070460389c673d973e4521d3dc Reviewed-on: https://go-review.googlesource.com/c/crypto/+/610797 Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Alan Donovan <[email protected]>
Change-Id: Ibd48a070bd8ce35ef5795a8b73bc4ecac43a993e Reviewed-on: https://go-review.googlesource.com/c/crypto/+/611735 Run-TryBot: shuang cui <[email protected]> Commit-Queue: Ian Lance Taylor <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
if a client is disconnected due to too many authentication attempts we should return a ServerAuthError instead of a generic error. Some users check the error returned by NewServerConn to determine whether or not a client attempted to authenticate. Fixes golang/go#69191 Change-Id: If68fcecdefd6c810fe9df8256b1216e320d8a916 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/566398 Reviewed-by: Filippo Valsorda <[email protected]> Reviewed-by: Tim King <[email protected]> Auto-Submit: Nicola Murino <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Carlos Amedee <[email protected]>
While both impractical and unlikely, the multiplication could overflow on 32-bit architectures. The 64-bit architecture case is unaffected by both the maximum length of Go slices being too small to trigger the overflow (everything except s390), and it being safe to assume no machine has more than 2 EiB of memory. Fixes golang/go#66232 Change-Id: I19c15d42d2d6af35e296697159d43d02f513e614 GitHub-Last-Rev: 503e180 GitHub-Pull-Request: #286 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/570876 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: Id321d3b5909ecb66c0311ba86008509c7895863b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/617958 Auto-Submit: Gopher Robot <[email protected]> Reviewed-by: David Chase <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
The cipher needs to load the stream in LE order. Use the byte reversing loads on BE. Also, remove the unused variable poly1305Mask in the PPC64 asm file too. Change-Id: Ie90fe7bb0ea7a3bcb76583e0cf9c1e4133499541 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/614298 Reviewed-by: Michael Knyszek <[email protected]> Reviewed-by: Archana Ravindar <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: David Chase <[email protected]>
This requires fixing an incorrect save of the counter. It is a word value. It happens to work on LE because length is limited to u32. Refactor the constant table to load correctly independent of byte ordering. Add byte order swapping where output needs converted to LE ordering for storage. Change-Id: Ic7e09bd1c769bb77dd6e817f5a8639ba765f4c0f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/614297 Reviewed-by: Cherry Mui <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> Reviewed-by: Archana Ravindar <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
…ve auth early Seems the OpenSSH server running on windows fails keyboard-interactive auth this way without sending any prompt to client. In such case the golang ssh client should not retry keyboard-interactive auth when the auth method is wrapped in a RetryableAuthMethod(). Rather the auth method should be immediately marked as tried&failed and the client auth process should move on to next available and acceptable auth method. Fixes golang/go#67855 Change-Id: I6c64ae58ff8325774e37af716601b112f8833d8f GitHub-Last-Rev: 7fafc4d GitHub-Pull-Request: #297 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/590956 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Auto-Submit: Nicola Murino <[email protected]> Reviewed-by: Nicola Murino <[email protected]>
Previously, the package worked by copying the input (or the output) into
a buffer, and then XOR'ing (or copying) it into (or out of) the state.
(Except for an input fast path.) There's no need for that! We can XOR
straight into the state, and copy straight out of it, at least on little
endian machines. This is a bit faster, almost halves the state size, and
will make it easier to implement marshaling, but most importantly look
at how much simpler it makes the code!
go: go1.23.0
goos: linux
goarch: amd64
pkg: golang.org/x/crypto/sha3
cpu: AMD Ryzen 7 PRO 8700GE w/ Radeon 780M Graphics
│ v0.27.0-2-g42ee18b9637 │ v0.27.0-2-g42ee18b9637-dirty │
│ sec/op │ sec/op vs base │
PermutationFunction-8 270.8n ± 0% 270.4n ± 0% ~ (p=0.099 n=10)
Sha3_512_MTU-8 5.762µ ± 0% 5.658µ ± 0% -1.80% (p=0.000 n=10)
Sha3_384_MTU-8 4.179µ ± 0% 4.070µ ± 0% -2.60% (p=0.000 n=10)
Sha3_256_MTU-8 3.316µ ± 0% 3.214µ ± 0% -3.08% (p=0.000 n=10)
Sha3_224_MTU-8 3.175µ ± 0% 3.061µ ± 0% -3.61% (p=0.000 n=10)
Shake128_MTU-8 2.779µ ± 0% 2.681µ ± 0% -3.51% (p=0.000 n=10)
Shake256_MTU-8 2.947µ ± 0% 2.957µ ± 0% +0.32% (p=0.000 n=10)
Shake256_16x-8 44.15µ ± 0% 44.45µ ± 0% +0.67% (p=0.000 n=10)
Shake256_1MiB-8 2.319m ± 0% 2.274m ± 0% -1.93% (p=0.000 n=10)
Sha3_512_1MiB-8 4.204m ± 0% 4.219m ± 0% +0.34% (p=0.000 n=10)
geomean 13.75µ 13.54µ -1.55%
│ v0.27.0-2-g42ee18b9637 │ v0.27.0-2-g42ee18b9637-dirty │
│ B/s │ B/s vs base │
PermutationFunction-8 704.3Mi ± 0% 705.4Mi ± 0% ~ (p=0.105 n=10)
Sha3_512_MTU-8 223.5Mi ± 0% 227.6Mi ± 0% +1.83% (p=0.000 n=10)
Sha3_384_MTU-8 308.1Mi ± 0% 316.4Mi ± 0% +2.67% (p=0.000 n=10)
Sha3_256_MTU-8 388.2Mi ± 0% 400.5Mi ± 0% +3.17% (p=0.000 n=10)
Sha3_224_MTU-8 405.5Mi ± 0% 420.7Mi ± 0% +3.73% (p=0.000 n=10)
Shake128_MTU-8 463.4Mi ± 0% 480.2Mi ± 0% +3.64% (p=0.000 n=10)
Shake256_MTU-8 436.9Mi ± 0% 435.5Mi ± 0% -0.32% (p=0.000 n=10)
Shake256_16x-8 353.9Mi ± 0% 351.5Mi ± 0% -0.66% (p=0.000 n=10)
Shake256_1MiB-8 431.2Mi ± 0% 439.7Mi ± 0% +1.97% (p=0.000 n=10)
Sha3_512_1MiB-8 237.8Mi ± 0% 237.1Mi ± 0% -0.33% (p=0.000 n=10)
geomean 375.7Mi 381.6Mi +1.57%
Even stronger effect when patched on top of CL 616555 (forced on).
go: go1.23.0
goos: darwin
goarch: arm64
pkg: golang.org/x/crypto/sha3
cpu: Apple M2
│ old │ new │
│ sec/op │ sec/op vs base │
PermutationFunction-8 154.7n ± 2% 153.8n ± 1% ~ (p=0.469 n=10)
Sha3_512_MTU-8 3.260µ ± 2% 3.143µ ± 2% -3.60% (p=0.000 n=10)
Sha3_384_MTU-8 2.389µ ± 2% 2.244µ ± 2% -6.07% (p=0.000 n=10)
Sha3_256_MTU-8 1.950µ ± 2% 1.758µ ± 1% -9.87% (p=0.000 n=10)
Sha3_224_MTU-8 1.874µ ± 2% 1.686µ ± 1% -10.06% (p=0.000 n=10)
Shake128_MTU-8 1.827µ ± 3% 1.447µ ± 1% -20.80% (p=0.000 n=10)
Shake256_MTU-8 1.665µ ± 3% 1.604µ ± 3% -3.63% (p=0.003 n=10)
Shake256_16x-8 25.14µ ± 1% 25.23µ ± 2% ~ (p=0.912 n=10)
Shake256_1MiB-8 1.236m ± 2% 1.243m ± 2% ~ (p=0.631 n=10)
Sha3_512_1MiB-8 2.296m ± 2% 2.305m ± 1% ~ (p=0.315 n=10)
geomean 7.906µ 7.467µ -5.56%
│ old │ new │
│ B/op │ B/op vs base │
PermutationFunction-8 1.204Gi ± 2% 1.212Gi ± 1% ~ (p=0.529 n=10)
Sha3_512_MTU-8 394.9Mi ± 2% 409.7Mi ± 2% +3.73% (p=0.000 n=10)
Sha3_384_MTU-8 539.0Mi ± 2% 573.8Mi ± 2% +6.45% (p=0.000 n=10)
Sha3_256_MTU-8 660.3Mi ± 2% 732.6Mi ± 1% +10.95% (p=0.000 n=10)
Sha3_224_MTU-8 687.1Mi ± 2% 763.9Mi ± 1% +11.17% (p=0.000 n=10)
Shake128_MTU-8 704.7Mi ± 2% 889.6Mi ± 2% +26.24% (p=0.000 n=10)
Shake256_MTU-8 773.4Mi ± 3% 802.5Mi ± 3% +3.76% (p=0.004 n=10)
Shake256_16x-8 621.6Mi ± 1% 619.3Mi ± 2% ~ (p=0.912 n=10)
Shake256_1MiB-8 809.1Mi ± 2% 804.7Mi ± 2% ~ (p=0.631 n=10)
Sha3_512_1MiB-8 435.6Mi ± 2% 433.9Mi ± 1% ~ (p=0.315 n=10)
geomean 653.6Mi 692.0Mi +5.88%
Change-Id: I33a0a1ddf305c395f99bf17f81473e2f42c5ce42
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/616575
Reviewed-by: Daniel McCarney <[email protected]>
Reviewed-by: Michael Pratt <[email protected]>
Reviewed-by: Roland Shoemaker <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Auto-Submit: Filippo Valsorda <[email protected]>
Reviewed-by: Andrew Ekstedt <[email protected]>
We used to compute the incorrect value if len(initBlock) % rate == 0. Also, add a test vector for golang/go#66232, confirmed to fail on GOARCH=386 without CL 570876. Fixes golang/go#69169 Change-Id: I3f2400926fca111dd0ca1327d6b5975e51b28f96 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/616576 Reviewed-by: Andrew Ekstedt <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
If you read a multiple of the rate, and then stop, there is no point in running the final permutation. Change-Id: Ic95e70f78b6e139aca1d3e3c11e09d2bbcf54f6c Reviewed-on: https://go-review.googlesource.com/c/crypto/+/620555 Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]>
Fixes golang/go#24617 Change-Id: I1d9d529950aa8a5953435e8d3412cda44b075d55 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/616635 Reviewed-by: Roland Shoemaker <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Michael Pratt <[email protected]>
These days people will just import the packages and the go tool will do the right thing. We don't need to explain it. Add a pointer to the git repo, though. For golang/go#62645 Change-Id: I8b1e4a877bd83fe6891688a44d27a6c7902c8979 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/624155 LUCI-TryBot-Result: Go LUCI <[email protected]> Commit-Queue: Ian Lance Taylor <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: Ib4976eb0b062bcd71c208afc9ff53e8c3068fbf9 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/626377 Reviewed-by: David Chase <[email protected]> Auto-Submit: Gopher Robot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
This is an automated CL which updates the NSS root bundle. Change-Id: Ic5267bf9d66b676e1cfc5fc2ae153afb8f33b29c Reviewed-on: https://go-review.googlesource.com/c/crypto/+/631635 Auto-Submit: Gopher Robot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Update golang.org/x dependencies to their latest tagged versions. Change-Id: I580d412fc4a135696d4054f8007593cfa4f64224 Reviewed-on: https://go-review.googlesource.com/c/crypto/+/633480 Reviewed-by: David Chase <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Gopher Robot <[email protected]>
Instead of a convoluted fake rand, it is _basically_ just as fast, and fixes errors that pop up due to bad entropy. Fixes golang/go#70682 Change-Id: Ib0f605398d1092b516b03135f602c644be2a060f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/633655 Reviewed-by: Tatiana Bradley <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Roland Shoemaker <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]>
Users of the the ssh package seem to extremely commonly misuse the PublicKeyCallback API, assuming that the key passed in the last call before a connection is established is the key used for authentication. Some users then make authorization decisions based on this key. This property is not documented, and may not be correct, due to the caching behavior of the package, resulting in users making incorrect authorization decisions about the connection. This change makes the cache a one entry FIFO cache, making the assumed property, that the last call to PublicKeyCallback represents the key actually used for authentication, actually hold. Thanks to Damien Tournoud, Patrick Dawkins, Vince Parker, and Jules Duvivier from the Platform.sh / Upsun engineering team for reporting this issue. Fixes golang/go#70779 Fixes CVE-2024-45337 Change-Id: Ife7c7b4045d8b6bcd7e3a417bdfae370c709797f Reviewed-on: https://go-review.googlesource.com/c/crypto/+/635315 Reviewed-by: Roland Shoemaker <[email protected]> Auto-Submit: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]> Reviewed-by: Nicola Murino <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 is so the fork remains in sync and up to date.