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>
Previously, an ECDSA crypto.Signer would have been expected to return a
signature in RFC7518 format, which violates crypto.Signer's interface
contract.
Fixesgolang/go#35829
Change-Id: Id0cc2d9296cfb9f89925ab9ac02e12d68eec734b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/209537
Run-TryBot: Filippo Valsorda <filippo@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>
This adds server-side support for the newly introduced OpenSSH
keytypes sk-ecdsa-sha2-nistp256@openssh.com and sk-ed25519@openssh.com
(including their corresponding certificates), which are backed
by U2F/FIDO2 tokens.
Change-Id: I53d5ed3d0457ae4758ee986055e187ee5787a2d1
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/208017
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Since there is no ClientAgent identifier, ExampleClientAgent wasn't
displayed as an example by godoc.
Change-Id: Ied8df7d8412c4aa483d42315986af49ba8fdbcef
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/208480
Reviewed-by: Dmitri Shuralyov <dmitshur@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>
Adds an error channel to the test helper function
testPortForward() to collect errors that happen inside
a goroutine.
Change-Id: I6db1d24b935fdfad637c971581ae80beaebd8a1f
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/207462
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the mod inverse of the private key's P value does not exist,
return an error in Decrypt rather than panic.
Change-Id: Ia075a60108863b14ba98bb62364a17131423b819
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/573976
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/205502
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
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 fixes an error variable that was being dropped
prior to the return of dhGroup.Server().
Change-Id: I8ddef1832cd7a62a69b61bb1c98bc1ceb561f985
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/205420
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.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>
Even on platforms that allow unaligned reads, the Go runtime assumes
that a pointer to a given type has the alignment required by that
type.
Fixesgolang/go#35173
Updates golang/go#34972
Updates golang/go#34964
Change-Id: I90361e096e59162e42ebde2914985af92f777ece
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/203837
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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's internal tokensMu is a bit overloaded and needs
a better name. This came up in golang.org/cl/199520.
Change-Id: I9b3c17cf0b64a35aea372738a1d1fad4a24cecb6
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/200680
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
Client's FetchCert now requires to do the discovery before
fetching a cert from RFC 8555 compliant CA using POST-as-GET
requests.
Some tests initialized the client without providing a directory
metadata, making it do network roundtrips to the default CA.
This CL sets a non-nil directory metadata to prevent unnecessary
network roundtrips to an actual CA during tests.
Change-Id: Icaa6c2c2fd25ae8e5b1b44c6c3dafa246e6bdbb0
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/200637
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This improves the performance of the asm implementation for
chacha20 on ppc64le by updating to the vsx implementation
provided in cryptogams. The previous implementation was found to
not perform as well as possible on power9. This implementation
improves performance on both power8 and power9.
Power9 improvement with this change as compared to current:
name old time/op new time/op delta
ChaCha20/32-64 361ns ± 0% 225ns ± 0% -37.67% (p=1.000 n=1+1)
ChaCha20/63-64 364ns ± 0% 229ns ± 0% -37.09% (p=1.000 n=1+1)
ChaCha20/64-64 364ns ± 0% 231ns ± 0% -36.54% (p=1.000 n=1+1)
ChaCha20/256-64 332ns ± 0% 199ns ± 0% -40.06% (p=1.000 n=1+1)
ChaCha20/1024-64 1.24µs ± 0% 0.70µs ± 0% -43.23% (p=1.000 n=1+1)
ChaCha20/1350-64 1.89µs ± 0% 1.03µs ± 0% -45.35% (p=1.000 n=1+1)
ChaCha20/65536-64 77.0µs ± 0% 42.5µs ± 0% -44.83% (p=1.000 n=1+1)
This is discussed in issue golang/go#25051.
A few asm instructions vmrgew and vmrgow were just added in Go 1.14
so have been encoded using WORD at this point.
Change-Id: I2b192a63cf46b0b20195e60e4412c43c5dd14ad8
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/195959
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
While working on the RFC 8555 implementation for golang/go#21081,
I've been also manually verifying the functionality against
various CAs both draft-02 and RFC versions.
This does not of course replace automated tests
yet it might be useful to others.
It is not a _test.go file because the program may require
interactive user input for dns-01 challenge types and needs
to flush logs to stderr during its run.
Change-Id: Ia324b08b30308441cc0705648e30c0112b0fa0c8
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/194681
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds RFC support to the existing methods which,
in conjunction with the new order based methods
implemented in golang.org/cl/192779, completes a Client
capable of obtaining certificates from RFC compliant CAs.
Updates golang/go#21081
Change-Id: I3aabc50928d3e4e49ee202eb6695135d5ad86821
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/194379
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The order based issuance flow is different from pre-authorization
in that users tell upfront which identifiers they want a future
certificate to contain and the CA responds with a set of authorizations
to satisfy.
Similar to pre-authorization where users start with Client's
Authorize method, fulfill challenges and then call GetAuthorization
or WaitAuthorization, the order based flow starts with AuthorizeOrder
and then GetOrder or WaitOrder.
Once all order authorizations are satisfied, users can call
CreateOrderCert, as opposed to the old CreateCert, and FetchCert as before.
The new method implementation and updates to the existing methods
is in golang.org/cl/194379.
More on order based flow can be found in
https://tools.ietf.org/html/rfc8555#section-7.4.
Updates golang/go#21081
Change-Id: I37c37203b50785d7681f65f815d7b19d9c15b96d
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/192779
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Most important change in this CL is that Client is now able
to correctly format and sign requests in KID form with a valid
"kid" value.
According to the RFC, most requests must include KID field
in the protected head of JWS requests. The KID value is the account
identity provided by the CA during registration.
The KID value is also the Account URL. Hence, the CL is tied to
account management.
Updates golang/go#21081
Change-Id: I13f51e1fc52db7596eb933b47fa2014beb93c1ab
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191602
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC8555 requires that most requests contain "kid" field in the
protected header. The JWK version is still used for new account
creation and certificate revocation requests. Previously,
in earlier drafts JWK variant was used exclusively.
While JWK is computed based off the account public key,
the new "kid" field takes literal value of the Account URL
provided by the CA during a new registration. The actual support
for KID-based JWS requests in Client will be added in a follow up CL.
For what concerns the existing behaviour of JWS requests,
a new field "url" is added to the protected header.
Before:
{"alg":"...", "jwk":"...", "nonce":"..."}
After:
{"alg":"...", "jwk":"...", "nonce":"...", "url":"..."}
where the new field takes a value of the target request URL.
This still works for CAs supporting pre-RFC protocol versions.
Updates golang/go#21081
Change-Id: I460cfcd3dfdfe7fe3009a92a0a8a709fa07d0e7a
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191601
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, nonce values were fetched from Directory URL.
RFC8555 and some recent drafts provide specific URL to fetch
new nonce values from.
This CL makes the client always use new nonce URL when available
and fall back to the previous behavior otherwise.
Updates golang/go#21081
Change-Id: I6442004b01d46aa015c193ca4c80daa712b78790
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/191603
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL is part of many to extend existing acme package
functionality to support RFC8555 without breaking existing users
of both this client package and CA implementations which haven't
caught up to the RFC spec.
Updates golang/go#21081
Change-Id: I20eb339ede019930c3482286cd13a3ba6f2b3cd6
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/182937
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The API changed for this function, since the call always succeeds.
Update this user of it accordingly.
Fixes: golang/go#34461
Change-Id: I9d19b70767fc6b1b9292ad8732dd8e54bb6a8ae0
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/196897
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These challenge types have been deprecated by popular ACME providers
due to security issues in the ecosystem.
Fixesgolang/go#28370
Change-Id: I3270a6f5d3e5fbc53e4347a9a802df5f603c87de
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/194658
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a space before build tag comments so it corresponds to the format
documented at https://golang.org/pkg/go/build/.
Change-Id: Ic29df4660a0968f58f721ec61943c0b277d4aaad
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/193777
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test just tests the behaviour of the host sshd in the face of
invalid terminal modes, and the RFCs say that the server "MAY" ignore
such modes (and newer openssh does in fact ignore these modes rather
than terminating the connection).
Fixesgolang/go#33919
Change-Id: I3f915aed22651e2eb33ec34044af8b125aeb82fa
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/192217
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The wasm runtime cannot schedule a GC run on tight loops.
Therefore it runs out of memory if such a loop allocates memory.
Skip such a test for now.
Updates golang/go#32840
Change-Id: I922b6e02710915776d2820573fd1584a5941185b
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Filippo Valsorda
Michael Munday
Katie Hockman
Ben Toews
edef
Filippo Valsorda
Sebastian Kinne
Fazlul Shahriar
Bryan C. Mills
Lars Lehtonen
Lynn Boger
Dmitri Shuralyov
Alex Vaghin
Scott Ragan
Brad Fitzpatrick
Jason A. Donenfeld
Eric Brown
Tobias Klauser
Michael Hudson-Doyle
yuanhh
Agniva De Sarker