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>
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>
Add the diffie-hellman-group-exchange-sha256 defined in RFC 4419 to
the list of supported key exchange algorithms for ssh.
The server half is only a minimal implementation to satisfy the automated tests.
Fixesgolang/go#17230
Change-Id: I25880a564347fd9b4738dd2ed1e347cd5d2e21bb
GitHub-Last-Rev: 9f0b8d02c0c96e9baf00cdf1cf063ff834245443
GitHub-Pull-Request: golang/crypto#87
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/174257
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Add asm implementation for chacha20 using vector instructions on ppc64le.
Below, the difference using the new code:
name old speed new speed delta
ChaCha20/32-16 167MB/s ± 0% 129MB/s ± 0% -22.60% (p=0.008 n=5+5)
ChaCha20/63-16 308MB/s ± 0% 249MB/s ± 0% -19.00% (p=0.008 n=5+5)
ChaCha20/64-16 357MB/s ± 0% 251MB/s ± 0% -29.57% (p=0.008 n=5+5)
ChaCha20/256-16 398MB/s ± 0% 1199MB/s ± 0% +201.20% (p=0.008 n=5+5)
ChaCha20/1024-16 413MB/s ± 0% 1398MB/s ± 0% +238.67% (p=0.008 n=5+5)
ChaCha20/1350-16 395MB/s ± 0% 1189MB/s ± 0% +200.71% (p=0.008 n=5+5)
ChaCha20/65536-16 420MB/s ± 0% 1489MB/s ± 0% +254.10% (p=0.008 n=5+5)
Small sizes are slower due the fact that it always calculates using
256 bytes of key stream.
This change was originally from Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
and started as CL 108999 (https://go-review.googlesource.com/c/crypto/+/108999).
Fixesgolang/go#25051
Change-Id: Ie510494249b227379e23d993467256b3d4088035
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/172177
Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Clone() made a copy of the Keccak state after invoking clone(), which is not
supported, since the "buf" slice in the Keccak state must point to the "storage"
array, and if the state is copied directly it will keep pointing to the storage
returned by clone().
Fix it by embedding a pointer to the Keccak state instead of the state itself.
Change-Id: I7d392963ec65d784a360f6c12a7935a9a9a788b5
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/173018
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
RFC 4880 uses the term "creation time" to refer to when keys and
signatures are created, and this is partially followed already. This
CL applies it to the rest of places that were using "currentTime"
instead.
Change-Id: I8a83604b53a240689327defd89e22ddbebe3b679
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/175446
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Aida Mynzhasova of SEC Consult Vulnerability Lab reported that the
clearsign package accepts some malformed messages, which can make it
possible for an attacker to trick a human user (but not a Go program)
into thinking unverified text is part of the message.
For example, if in the following message the vertical tab character is
printed as a new line, a human observer could believe that the
unverified header text is part of the signed message.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1\x0b\x0bThis text is part of the header.
Hello world!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iJwEAQECAAYFAk8kMuEACgkQO9o98PRieSpMsAQAhmY/vwmNpflrPgmfWsYhk5O8
[...]
MyTpno24AjIAGb+mH1U=
=hIJ6
-----END PGP SIGNATURE-----
The OpenPGP specs are delightfully vague about purpose and validation of
these headers. RFC 4880, Section 7 says
The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line,
- One or more "Hash" Armor Headers,
- Exactly one empty line not included into the message digest,
[...]
but also
If MD5 is the only hash used, then an
implementation MAY omit this header for improved V2.x compatibility.
and
If more than one message digest is used in the signature, the "Hash"
armor header contains a comma-delimited list of used message digests.
which seems to suggest that there can be zero or more Hash headers, each
with one or more algorithms, and no other header types.
Anyway, it's entirely unclear what security purpose, if any, the Hash
header accomplishes. If the hash is too weak to be secure or
unsupported, the verification will fail. Otherwise, the user shouldn't
care. Given its dubious function, avoid breaking abstractions to check
that it matches the signature, and just document it as unverified.
As for valid characters, RFC 4880 is silent, except reluctantly
mentioning that the Comment header can be UTF-8, but I am going to
assume that all hash algorithms will have ASCII names, because come on.
Even more importantly, reject non-Hash SIGNED MESSAGE headers (as opposed
to the SIGNATURE headers), to prevent a "Thank you!" message turning into
-----BEGIN PGP SIGNED MESSAGE-----
Reminder: I need you to wire $100k to 12345566 as soon as possible.
Thank you!
-----BEGIN PGP SIGNATURE-----
[...]
While at it, also check for trailing characters after the signed message
delimiter, as they are invalid and can be similarly used to confuse humans.
The Decode API is also unfortunate in that it doesn't return an error,
so we can't tell the user what's wrong with the message, but that's what
we've got.
Change-Id: I8a72c4851075337443d7a27e0b49a6b6e39f5a41
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/453011
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/173778
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
According to the [RFC 5280, section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6):
> ...
> When the subjectAltName extension contains a domain name system
> label, the domain name MUST be stored in the dNSName (an IA5String).
> The name MUST be in the "preferred name syntax", as specified by
> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
> [RFC1123]. Note that while uppercase and lowercase letters are
> allowed in domain names, no significance is attached to the case.
> ...
And the [RFC 1034, section 3.5](https://tools.ietf.org/html/rfc1034#section-3.5):
> ...
> Note that while upper and lower case letters are allowed in domain
> names, no significance is attached to the case. That is, two names with
> the same spelling but different case are to be treated as if identical.
> ...
We should return the same TLS certificate for both `example.com` and `EXAMPLE.COM`. But the `autocert.Manager.GetCertificate` treats the two as totally different, it signs and returns two different TLS certificates.
Moreover, now the `autocert.Manager.GetCertificate` and the `autocert.HostWhitelist` can only handle Punycode IDN. If the client sends a Unicode IDN to `autocert.Manager.GetCertificate` (cURL is doing this), the "Invalid character in DNS name" error will be triggered.
This PR corrects these problems by converting the host of the TLS certificate to be obtained to Punycode via `idna.Lookup.ToASCII`.
Change-Id: I993821b3a6ae532a53772e2db00524479ef111af
GitHub-Last-Rev: 6c12694574b6ac71a920da8a8bdb130c0b6e0272
GitHub-Pull-Request: golang/crypto#85
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/171997
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
At the protocol level, SSH lets client and server specify different
algorithms for the read and write half of the connection. This has
never worked correctly, as Client-to-Server was always interpreted as
the "write" side, even if we were the server.
This has never been a problem because, apparently, there are no
clients that insist on different algorithm choices running against Go
SSH servers.
Since the SSH package does not expose a mechanism to specify
algorithms for read/write separately, there is end-to-end for this
change, so add a unittest instead.
Change-Id: Ie3aa781630a3bb7a3b0e3754cb67b3ce12581544
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/172538
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new name readCipherPacket/writeCipherPacket disambiguates method
calls from packetConn.{read,write}Packet, which has a different
signature, and is called in different layers of the stack.
Change-Id: I02ca83e28f74f0a347a1cde665efdfb78f3f51bb
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/171657
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before, we emitted N single-move sequences on a cursor move. For
example, "move 4 left" would emit "^[[D^[[D^[[D^[[D". With this change,
it would emit "^[[4D".
Using variable move sequences when possible reduces the amount of
rendering output that the terminal implementation produces. This can
have some low-level performance benefits, but also helps consumers
reason through the produced output.
Includes a test with a couple of cases.
Note: The old implementation used ^[[D instead of ^[D which is also
valid. This is true in several unrelated places, so this implementation
continues to use ^[[D for consistency.
Change-Id: If38eaaed8fb4075499fdda54c06681dc34c3ad70
GitHub-Last-Rev: 92ef2538d33a9493f3df09984c277dfd8bf0abf4
GitHub-Pull-Request: golang/crypto#82
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/169077
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL adds the poly1305.MAC type which implements a
subset of the hash.Hash interface. With MAC it is possible
to compute an authentication tag of data without copying
it into a single byte slice.
This commit modifies the reference/generic and the
AMD64 assembler but not the ARM/s390x implementation
to support an io.Writer interface.
Updates golang/go#25219
Change-Id: I7ee5a9eadd43387cf3cd887d734c625575eee47d
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/111335
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Alex Vaghin
Lynn Boger
Scott Ragan
Brad Fitzpatrick
Jason A. Donenfeld
Eric Brown
Tobias Klauser
Michael Hudson-Doyle
yuanhh
Agniva De Sarker
Filippo Valsorda
Lucas Bremgartner
Carlos Eduardo Seo
Conrado P. L. Gouvea
yanweizhi
Matthew Dempsky
Udalov Max
chigotc
Aofei Sheng
Han-Wen Nienhuys
Kris Kwiatkowski
Neven Sajko
Andrey Petrov
Michael McLoughlin
Andreas Auernhammer