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>
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>
Lars Lehtonen
Katie Hockman
Filippo Valsorda
Lynn Boger
Bryan C. Mills
Dmitri Shuralyov
Alex Vaghin
Scott Ragan
Brad Fitzpatrick
Jason A. Donenfeld
Eric Brown
Tobias Klauser
Michael Hudson-Doyle
yuanhh
Agniva De Sarker
Lucas Bremgartner
Carlos Eduardo Seo
Conrado P. L. Gouvea
yanweizhi
Matthew Dempsky
Udalov Max
chigotc