The change should reduce resource quota consumed by the client overall.
Instead of sending HEAD to an ACME resource URL to get a new nonce,
the Client will now try to fetch it from the Directory URL first
and only then from the ACME resource URL if the former fails.
This builds up on an abandoned https://golang.org/cl/34623,
only this time with a fallback to the original behaviour.
Change-Id: I6e75c0e524c4bc751f3a651b290c0ac2493e0628
Reviewed-on: https://go-review.googlesource.com/c/162057
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Comparison against BoringSSL-generated test vectors showed mismatches
with the pure Go implementation of curve25519. The problem was narrowed
down to a missing mask in feFromBytes(). This diff adds the mask,
bringing this back in line with the reference implementation and
RFC 7748:
When receiving such an array, implementations of X25519 (but not
X448) MUST mask the most significant bit in the final byte. This is
done to preserve compatibility with point formats that reserve the
sign bit for use in other protocols and to increase resistance to
implementation fingerprinting.
Fixesgolang/go#30095
Change-Id: If7efc0e2acd6efb761d6e3cb89cec359d7d81cb1
Reviewed-on: https://go-review.googlesource.com/c/161257
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
audited using ineffassign tool from
github.com/gordonklaus/ineffassign
go generate does not generate any changes
Change-Id: Iabbec9ec1aae39081289d503d79fd7b4caadf17b
GitHub-Last-Rev: acd17cce410e9c68ce3c87b5546261be9153e3ea
GitHub-Pull-Request: golang/crypto#70
Reviewed-on: https://go-review.googlesource.com/c/155942
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Addition of a DecodeAll function as it was mentioned in #14015.
This solves a need many people seem to have, where there is no effective
way loading PKCS12 files that contain more than one certificate and one
private key.
The utility functions used by Decode are all internal, which makes
implementing this on the user-side tedious, hence the suggestion of
providing a more liberal version of the function: DecodeAll.
Fixesgolang/go#14015
Change-Id: I03c541553b6cb488c2c59d39575342a43136e592
GitHub-Last-Rev: 05f6847ff80ca34c92a01a688c7b81e874af3009
GitHub-Pull-Request: golang/crypto#38
Reviewed-on: https://go-review.googlesource.com/c/105876
Reviewed-by: Adam Shannon <adamkshannon@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Keccak uses a different domain separation byte as the NIST-
standardized SHA-3 hashing function. A previous commit to
this package added support for Keccak-256, but did not do
so for Keccak-512. The reasoning was to support use cases
like Ethereum, however Ethereum also uses Keccak-512 for
the Ethash PoW, so this second method is also needed.
Prev CL: https://go-review.googlesource.com/c/crypto/+/106462Fixesgolang/go#29533
Change-Id: I9d92b1f121657f631c157e5e309771db1cd91c82
Reviewed-on: https://go-review.googlesource.com/c/125795
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously MulScalar was ignoring the first parameter, which was inconsistent with gfp6 and gfp2.
Change-Id: I4f4a4ca2f07a25176ab159be684a02696f1580ba
GitHub-Last-Rev: ec40c0403614ed56cf329102eb274dc776fa3be8
GitHub-Pull-Request: golang/crypto#67
Reviewed-on: https://go-review.googlesource.com/c/154457
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
SHA384 is a natural hashing choice for P-384 ECDSA. The only thing
needed to make it usable, is adding it to the list of candidates.
Change-Id: I61f66f371774f95dfc1de30d10fab66f92c21b6b
Reviewed-on: https://go-review.googlesource.com/c/137956
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Builders created with NewFixedBuilder were broken when used with
BuilderContinuations. The length of the bytes written to the
continuation would get added correctly to the parent, but the actual
content would be discarded.
For example, the BytesOrPanic() in TestFixedBuilderLengthPrefixed would
return [00 08] instead of [00 08 ff ff ff ff ff ff ff ff].
Change-Id: I80837a9bf3562751addcb827274649d9f52fc79a
Reviewed-on: https://go-review.googlesource.com/c/148882
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Previously, this would return the default error "no auth passed yet".
Not only is the new error more specific, it makes it easier to verify
the control flow of server authentication code.
Change-Id: I6c8de4e3f91da74274acbe9d87ec4f6158b4a94f
Reviewed-on: https://go-review.googlesource.com/c/142897
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, only rsa.PrivateKey and ecdsa.PrivateKey are supported
when creating JWS signatures. However, it is unnecessarily limiting
because any crypto.Signer implementation can sign a digest
in the appropriate format.
This change uses key.Public() instead of type-asserting the private
key which allows for a custom crypto.Signer implementation.
For instance, a key stored in a hardware module where the latter
does the actual signing without the key ever leaving its boundaries.
Change-Id: Ie7930ea2ba8c49dde7107ff074ae34abec05bdb9
Reviewed-on: https://go-review.googlesource.com/c/145137
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Make sure a meaningful error is returned when the SSH agent client receives
a response that is too big.
Change-Id: Ied68b2c559a61dede2f3112c4c8143babd385f48
GitHub-Last-Rev: ad65e1b423bb00f2501dfde84040469aef4ee2df
GitHub-Pull-Request: golang/crypto#61
Reviewed-on: https://go-review.googlesource.com/c/143058
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently the benchmarks hard code "10" for the cost but maybe a
better benchmark would be to use the DefaultCost, since this is the
most common use mode for the bcrypt package.
Change-Id: Ie89853fcbe4a3a2830fff812ae5cfe908df145fe
Reviewed-on: https://go-review.googlesource.com/c/144338
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Unwrite allows programs to rollback builders more reliably and
efficiently than by copying a Builder (which might waste an allocation
and depends on internal behavior). This is useful for example to remove
a length-prefixed field if it ends up being empty.
SetError allows simple Builder extensions to set errors without making
MarshalingValue wrappers.
Based on the experience of CL 144115.
Change-Id: I9a785b81b51b15af49418b5bdb71c4ef222ccc46
Reviewed-on: https://go-review.googlesource.com/c/145317
Reviewed-by: Adam Langley <agl@golang.org>
This commit implements two new features. To preserve backwards
compatibility the new methods are added to an `ExtendedAgent` interface
which extends `Agent`. The client code implements `ExtendedAgent`
(which extends Agent) so you can call these additional methods against
SSH agents such as the OpenSSH agent. The ServeAgent method still
accepts Agent but will attempt to upcast the agent to `ExtendedAgent`
as needed, so if you supply an ExtendedAgent implementation you can
implement these additional methods (which keyring does).
The first feature is supporting the standard flags that can be passed to
SSH Sign requests, requesting that RSA signatures use SHA-256 or
SHA-512. See section 4.5.1 of the SSH agent protocol draft:
https://tools.ietf.org/html/draft-miller-ssh-agent-02
The second feature is supporting calling custom extensions from clients
and implementing custom extensions from servers. See section 4.7 of the
SSH agent protocol draft:
https://tools.ietf.org/html/draft-miller-ssh-agent-02
Change-Id: I0f74feb893762c27e921ec37604d3a46434ee6ef
GitHub-Last-Rev: 2e23fd01c0e95b664e8507682f0bd5bd61d4c146
GitHub-Pull-Request: golang/crypto#53
Reviewed-on: https://go-review.googlesource.com/c/123955
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.
TLS 1.3 also needs direct access to both Extract and Expand.
pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.
Fixesgolang/go#28237
Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
More informative error message enables HTTPS server configuration mistakes to be corrected quickly, since log files will now include the rejected hostname. If the hostname should be accepted, it can be added to the HostWhitelist Policy.
Fixesgolang/go#28345
Change-Id: I801c82f0d3b19bc34592c9cd0bce77f1b284d19d
GitHub-Last-Rev: 5dfe731d732d693f9bdd79c8a74efd30a2f56d0b
GitHub-Pull-Request: golang/crypto#63
Reviewed-on: https://go-review.googlesource.com/c/144337
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix typo in error message when keyboard-interactive auth not supported by server and client requests it
Change-Id: Iedb72625852f03552481d85cce2119765cfba320
GitHub-Last-Rev: ee47092daf8c40fe3e0e166e7370556819457af6
GitHub-Pull-Request: golang/crypto#59
Reviewed-on: https://go-review.googlesource.com/c/141658
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
keys_test.go was slowing down my editor because it was getting too
large. It helps to remove the keys of the file as they contain extremely
long lines and large strings.
Change-Id: I8d193179ddc32438b7233f0f9ca8c57c928a0436
Reviewed-on: https://go-review.googlesource.com/c/138997
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Test for RFC4880 5.2.3.3:
> An implementation that encounters multiple self-signatures on the
> same object may resolve the ambiguity in any way it sees fit, but it
> is RECOMMENDED that priority be given to the most recent self-
> signature.
Note: Some GPG implementation will reorder the packets for you when
exporting keys. This makes it complicated to generate a key for this
test. Should someone have to create a similar key again, look into
gpgsplit, gpg --dearmor, and gpg --enarmor. These keys exist in the
wild too.
Change-Id: I5d46054ebbc95407d644e4e462d777aab290794c
Reviewed-on: https://go-review.googlesource.com/138215
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Rather than using the first subkey binding signature encountered, use
the one with the most recent creation data, as per the recommendation from
RFC 4880:
> An implementation that encounters multiple self-signatures on the
> same object may resolve the ambiguity in any way it sees fit, but it
> is RECOMMENDED that priority be given to the most recent self-
> signature.
This allows subkeys to approach expiry then be re-signed with a new expiry.
This extends the recent commit 0e37d00 by @aviau and @FiloSottile.
Fixesgolang/go#26468
Change-Id: I7f12706727373259c188bfee4254306ef9d4e935
GitHub-Last-Rev: 0da814166411a3c3334312576d3f7f8f2bba4ff4
GitHub-Pull-Request: golang/crypto#57
Reviewed-on: https://go-review.googlesource.com/135357
Reviewed-by: Filippo Valsorda <filippo@golang.org>
In change id Id992676ef2363779a7028f4799180efb027fcf47, "current" was
moved into the UserID packet handling scope. This was the only thing
preventing us to move the UserID packet handling code inside its own
function.
This patch moves the UserID packet handling code inside a new addUserID
function. This is consistent with the other existing addSubKey method.
"current" is renamed to "identity" for improved readability.
Change-Id: I5d58eb35ab5fa9fc7d9d111fa186fec6f5e11e79
Reviewed-on: https://go-review.googlesource.com/118959
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Consider the following packet ordering scenario:
PUBKEY UID SELFSIG SUBKEY REV SELFSIG
In this scenario, addSubkey would only consume the REV signature after
the subkey, leaving SELFSIG to be read by ReadEntity, which in turn
would add the last SELFSIG to the UID's signatures, which is wrong to do
because this is a SUBKEY SELFSIG, not a UID signature.
Remove "current" from the ReadEntity scope, it should only be visible
to the UserId packet handling code.
Keep the warning about signature packets found before user id packets.
Without it, I would not have found this bug.
Modify addSubKey so that it consumes all signatures following the SUBKEY
packet, keeping eithier the first valid signature (like we did before)
or any valid revocation.
In a follow-up patch, we can improve this further by keeping the
most recent signature, as suggested by RFC4880:
> An implementation that encounters multiple self-signatures on the
> same object may resolve the ambiguity in any way it sees fit, but it
> is RECOMMENDED that priority be given to the most recent self-
> signature.
Fixesgolang/go#26449
Change-Id: Id992676ef2363779a7028f4799180efb027fcf47
Reviewed-on: https://go-review.googlesource.com/118957
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Avoid using package specific variables when there is a one to one
correspondance to cpu feature support exported by internal/cpu.
This makes it clearer which cpu feature is referenced.
Another advantage is that internal/cpu variables are padded to avoid
false sharing and memory and cache usage is shared by multiple packages.
Change-Id: Ieadfc2f2f65f83f947aa8a5efc869aa85d89615d
Reviewed-on: https://go-review.googlesource.com/126597
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The timeNow package variable doesn't work well here: since the renewal
functionality spawns goroutines that invoke timeNow, once a test has
caused such goroutines to exist, another test can't fiddle with it
without the race detector triggering.
Instead, have a private member of Manager that the tests can set if they
need.
Change-Id: Iaf1a68d8efb84c9c5e2804aeb9cc6b2d3f3fef43
Reviewed-on: https://go-review.googlesource.com/128655
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Alex Vaghin
Meng Zhuo
Michael McLoughlin
Michael Cook
Filippo Valsorda
Filippo Valsorda
Julien Kauffmann
Michal Bohuslávek
Jay Taylor
Ross Smith II
Péter Szilágyi
kc1212
Axel Wagner
Tobias Klauser
Philipp
chigotc
Han-Wen Nienhuys
Ian Haken
Kevin Burke
Igor Zhilianin
David Jones
Andres Lowrie
mkishere
aviau
Paul M Furley
Adam Langley
David Ndungu
Martin Möhrmann
Thomas Bushnell, BSG
Noel Georgi