This requirement is from RFC 4880 4.2.2.4.
Also simplify the partialLengthWriter loop. The old code worked but
was written in a confusing way, with a loop whose terminating condition
didn't make sense and was never true in practice.
Rewrite it to more clearly do a set of partial writes of decreasing size.
Fixesgolang/go#32474
Change-Id: Ia53ceb39a34f1d6f2ea7c60190d52948bb0db59b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/181121
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
An attacker can craft an ssh-ed25519 or sk-ssh-ed25519@openssh.com
public key, such that the library will panic when trying to verify a
signature with it. Clients can deliver such a public key and signature
to any golang.org/x/crypto/ssh server with a PublicKeyCallback, and
servers can deliver them to any golang.org/x/crypto/ssh client.
This issue was discovered and reported by Alex Gaynor, Fish in a Barrel,
and is tracked as CVE-2020-9283.
Change-Id: Ie25b78a0b0181fbbc8cc7de4f4e27d908777529c
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/220357
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 212377 changed end of input character on windows - from \n to \r.
But CL 212377 did not adjust ReadConsole accordingly. For example,
after CL 212377 \n was still used to end of password processing,
and \r was ignored.
This CL swaps these rules - \r is now used to end password processing,
and \n are ignored. The change only affects windows, all non windows
code should work as before.
This CL also adjusts TestReadPasswordLineEnd to fit new rules.
Fixesgolang/go#36609
Change-Id: I027bf80d10e7d4d4b17ff0264935d14b8bea9097
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/215417
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
RFC 4800, Section 6 specifies that the CRC at the end of the
armor is optional, so do not fail to decode signatures missing
the CRC.
Credit: armor.go patch from engineer at Google
Change-Id: I39b04e0afaaafdf7aa86577fe4a35c50e7cf0b2b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/215022
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
An illegal instruction would occur due to a bug in the way input
slices were rounded down in size to a multiple of the rate for a
given hash type. This would only occur when the Write function
was called with more than ~3KiB of data and the length of the data
was not a multiple of the rate.
Fixesgolang/go#36459.
Change-Id: I621ef8d75602bcd59bb44491e17f721050001e6d
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/213857
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
https://github.com/google/wycheproof provides test vectors exposing
vulnerabilities in crypto packages. This change creates a new package
called internal/wycheproof that runs these Wycheproof tests against
a number of pacakages in the standard library (and in the future,
x/crypto).
Directory structure:
- interal/wycheproof/internal/ecdsa: internal version of ecdsa package which
includes a new function that verifies ASN encoded signatures directly
- interal/wycheproof/internal/dsa: internal version of dsa package which
includes a new function that verifies ASN encoded signatures directly
- internal/wycheproof: all tests
internal/wycheproof/wycheproof_test.go provides utility functions that are
common to many tests in the package, and contains the TestMain which
fetches github.com/google/wycheproof from the source.
This change includes tests for signature verification with dsa, ecdsa,
eddsa, and rsa (both PKCS#1 v1.5 and PSS signatures).
Note that these tests download testdata from github.com/google/wycheproof
by running `go mod download` in the TestMain. This means that internet
access will be necessary in order to run these tests if the testdata is
not already in your module cache.
More tests will be added incrementally.
Change-Id: I0378d4be24b5679fdc186e9fc94c1cc0068e81f7
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/209221
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The behavior of ParsePrivateKeyWithPassphrase when the key is
unencrypted is unspecified. Currently, it just parses them like
ParsePrivateKey, which is unlikely to be what anyone wants: for us to
ignore a passphrase that they explicitly passed. It also makes the
implementation of encrypted OpenSSH keys in the next CL more confused.
Instead, make ParsePrivateKey return a PassphraseNeededError, so the
application logic can be ParsePrivateKey -> detect encrypted key ->
obtain passphrase -> ParsePrivateKeyWithPassphrase. That error will also
let us return the public key for OpenSSH keys.
Change-Id: Ife4fb2499ae538bef36e353adf9bc8e902662386
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/207599
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
First, modify the test to report a better error by waiting for the
Marshal+Write goroutine to finish before returning from the test. If we
return too early, a failure inside that goroutine can generate a panic.
Second, we workaround plan9 not returning the actual number of bytes
written on the connection in case of a hangup (due to closed
connection). I've verified that syscall.Pwrite returns -1 on hangup in
this particular case even when some data did get written.
Fixesgolang/go#35888
Change-Id: I7998cff926295f0d577b125c137021a9adc1be5a
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/209298
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Certain environment variables can influence the behavior of ssh-agent,
causing the test to fail. Avoid that influence by using a consistent
environment.
This fixes a locally-observed test failure for me.
Change-Id: I0f5e8d643199519f88e80825335ee8e6eb08e3af
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/207901
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Simply add the NonceSizeX constant, and accept 24 bytes nonces in
NewUnauthenticatedCipher. Based on draft-irtf-cfrg-xchacha-01 and
libsodium's implementation.
Fixesgolang/go#24485
Change-Id: I551c8ace258bd54b95bb204c8bb34bccd1c4b615
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/185991
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Separated the complex buffering logic from key stream generation more
clearly, added plenty of comments and generally refactored the Go
implementation for readability. Made the interface with the
generic/assembly cores smaller and more consistent, according to
golang.org/wiki/TargetSpecific.
We will recover the lost performance on unaligned calls by caching 3/4
of the first round across XORKeyStream invocations, which we now have
complexity budget for.
name old speed new speed delta
ChaCha20/64-4 435MB/s ± 2% 429MB/s ± 2% -1.47% (p=0.013 n=10+9)
ChaCha20/256-4 496MB/s ± 1% 493MB/s ± 2% ~ (p=0.280 n=10+10)
ChaCha20/10x25-4 283MB/s ± 1% 274MB/s ± 2% -3.13% (p=0.000 n=10+10)
ChaCha20/4096-4 494MB/s ± 1% 493MB/s ± 5% ~ (p=0.631 n=10+10)
ChaCha20/100x40-4 421MB/s ± 3% 408MB/s ± 1% -3.14% (p=0.003 n=9+9)
ChaCha20/65536-4 515MB/s ± 1% 519MB/s ± 3% ~ (p=0.161 n=7+10)
ChaCha20/1000x65-4 501MB/s ± 2% 501MB/s ± 3% ~ (p=0.497 n=9+10)
Also applied a fix for a lingering bug in the ppc64le assembly written
by Lynn Boger <laboger@linux.vnet.ibm.com>.
Updates golang/go#24485
Change-Id: I10cf24a7f10359b1b4ae63c9bb1946735b98ac9b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/185439
Reviewed-by: Michael Munday <mike.munday@ibm.com>
This corrects a compile error due to a mismatch between function
description and the assembler code that first appeared when running
TryBots on the change to vendor this code. This fixes that problem
and adds and minor change based on a comment in CL 195959.
Change-Id: I42cbd3f75e281913f12f74850deaedf14eb21989
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/205659
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Previously, the o.AuthzURLs slice was sometimes used from the call to
client.WaitOrder at the bottom of the for loop.
By that point, o may be nil if client.WaitOrder returned an error,
which would cause a nil pointer dereference panic inside the deferred
function call. If client.WaitOrder did not return an error, then the
call to deactivatePendingAuthz would use its AuthzURLs slice instead
of the one from client.AuthorizeOrder.
Fixesgolang/go#35225
Updates golang/go#21081
Change-Id: I7db055ee1149871b6e5d34a8618526899c68f827
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203919
Reviewed-by: Alex Vaghin <ddos@google.com>
The Manager now uses RFC 8555 implementation of Let's Encrypt by default.
Existing users need not do any manual upgrades. If you vendor
acme/autocert, it is enough to just rebuild your binaries at this CL.
If there's an account key stored in Manager's cache which has been used
with an earlier Let's Encrypt implementation (aka v1 or draft-02),
it will be automatically re-registered with the new endpoint.
One notable change is the CAServer from internal/acmetest was amended
to simulate a CA implementing RFC 8555, replacing draft-02.
Support for both RFC and draft-02 seemed too complicated and not worth
the benefits: the old pre-RFC bits will be removed from both acme and
acme/autocert packages at some point.
Fixesgolang/go#21081
Change-Id: Id530758ac612b1c20f9df51c4d10f770e5f41ecf
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/199520
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>