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: ec40c04036
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>
Enable the tests on aix after support was added in CL 151077.
Change-Id: I2dcdaaa54d7c27b7697224e0f3cfab3cf0b52b6a
Reviewed-on: https://go-review.googlesource.com/c/151437
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Clément Chigot <clement.chigot@atos.net>
Reviewed-by: Ian Lance Taylor <iant@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: ad65e1b423
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: 2e23fd01c0
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>
These are deprecated according to RFC4880 and should no longer be
generated: https://tools.ietf.org/html/rfc4880#section-13.5
With that, the notion of a "sign-only" private key doesn't make sense
(as that is a signature property, not a private key property), so remove
it from the comment.
Fixesgolang/go#27888
Change-Id: I7d41acd0793b2caf3c0897e580f42375c72d82a8
Reviewed-on: https://go-review.googlesource.com/c/137896
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@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: 5dfe731d73
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: ee47092daf
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: 0da8141664
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>
Because tls.Config now requires more fields to be set
in order for tls-alpn to work, Manager provides a new
TLSConfig method for easier setup.
This CL also adds a new internal package for end-to-end tests.
The package implements a simple ACME CA server.
Fixesgolang/go#25013Fixesgolang/go#25901
Updates golang/go#17251
Change-Id: I2687ea8d5c445ddafad5ea2cdd36cd4e7d10bc86
Reviewed-on: https://go-review.googlesource.com/125495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ACME draft specifies the CA servers should respond
with 201 Created status code but Let's Encrypt
responds with 202 Accepted when creating a new account.
This change adds 202 Accepted as a valid response.
Otherwise, the Client hangs while doing retries,
discarding 202 responses as invalid.
Tests are not updated intentionally
due to this being non-conformant with the spec.
Fixesgolang/go#26251
Change-Id: I2918fce3873592c02e96f4118c4d1ecb42da3c4f
Reviewed-on: https://go-review.googlesource.com/125415
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is neither a '--clearsign' nor a '--detach-sign' which are already
supported. Verification of these signatures is already supported by
ReadMessage.
The code shares a lot with standard encrypt/sign, so mostly a
refactoring of 'Encrypt' to allow use of the code path without
actually doing a signing.
Change-Id: I5bb7487134ffcf1189ed74e28dbbbe1c01b356d1
GitHub-Last-Rev: 0116222260
GitHub-Pull-Request: golang/crypto#50
Reviewed-on: https://go-review.googlesource.com/116017
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The retry logic returns an "acme: no more retries for ..." error
in some cases, while *Error type in others.
This change makes retries always return the last error as received
from the CA server, if available. No change in returned values
of successful requests.
Change-Id: I3df2cb332a3e2739bba457c0ee50d7ca5bd836d9
Reviewed-on: https://go-review.googlesource.com/119975
Reviewed-by: Maciej Dębski <maciejd@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new package subtle added in golang.org/cl/112236 breaks
compatibility with App Engine due to the import of unsafe.
This changes adds an App Engine alternative without using unsafe.
Tested with:
$ go test -test.tags=appengine -v
=== RUN TestAliasing
--- PASS: TestAliasing (0.00s)
PASS
ok golang.org/x/crypto/internal/subtle 0.009s
Change-Id: I2fc6b02a860b3ee11fa31652ba302fc7db9df153
Reviewed-on: https://go-review.googlesource.com/119095
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Just ran
gofmt -w .
on the project root. That's all.
Change-Id: Ia90223dda399c1df67e7bcf75c6773de63902cc8
GitHub-Last-Rev: 8ba80b9676
GitHub-Pull-Request: golang/crypto#52
Reviewed-on: https://go-review.googlesource.com/119375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Signing was moved in NewEntity as it makes more sense there, but there
might be code that relies on SerializePrivate to make signatures with
parameters that were modified after NewEntity.
As it used to always sign in SerializePrivate, it shouldn't break
anything to sign in both places.
Fixesgolang/go#25463
Change-Id: Ia7f509daf31ac05fedc441225d554f333b288d70
Reviewed-on: https://go-review.googlesource.com/118015
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Yaron de Leeuw <jarondl@google.com>
Reviewed-by: Alexandre Viau <viau.alexandre@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When failing, TestKeyExpiry would output the wrong expected key id. It
would output "Expected key 1ABB25A0" instead of "Expected key 96A672F5".
Avoid this mistake by declaring the variable only once and using it in
the error format.
Change-Id: I860d82bf2c7fa80558051cdb21a41d506e95c25f
Reviewed-on: https://go-review.googlesource.com/118958
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing code was wrongly assuming that UserID packets must be
immediately followed by a Signature packet. However, this is not true.
See RFC4880 11.1:
> Immediately following each User ID packet, there are zero or more
> Signature packets.
This change will ensure that Entities that are not immediately followed
by a Signature packet are read without raising a StructuralError.
Instead, UserID packets that are not immediately followed by a self
signature will be ignored.
Maximum backwards compatibility is retained because revoked UserIDs are
not added to the Entity's identities.
In a follow-up patch, we should probably add these UserIDs to the
Entity's identities too, but not without making sure that the revocation
is also available in the Entity's (or the Identity's) Revocations slice.
This would require adding support for a new Signature Type,
"Certification revocation signature", as defined in RFC 48880 5.2.1.
Fixesgolang/go#25850
Change-Id: Idde34b97429998f28e0c687171024e51ed959bf0
Reviewed-on: https://go-review.googlesource.com/118376
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
AnyOverlap and InexactOverlap implement checks for the aliasing
requirements defined by the crypto/cipher interfaces. Apply them to all
implementations as the actual requirement could be architecture-dependent
and user code should not rely on undefined behavior.
Updates golang/go#21624
Change-Id: I465de02fb3fec4e0c6f1fdee1ef6ae7ed5abff10
Reviewed-on: https://go-review.googlesource.com/112236
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To comply with the specification the value of the extension should be a ASN.1
OCTET STRING rather than a raw SHA 256 hash. This change uses asn1.Marshal to
wrap the hash before putting it in the extension.
Change-Id: I4ebe88a00238c6f928555d605e4b5dd98aad8128
Reviewed-on: https://go-review.googlesource.com/118696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Péter Szilágyi
kc1212
Axel Wagner
Tobias Klauser
Philipp
chigotc
Filippo Valsorda
Han-Wen Nienhuys
Alex Vaghin
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
Wilfried Teiken
ia
Roland Shoemaker