Having a trailing comma before a space doesn't mean that the next option
will be ANDed rather than ORed. This worked with the standard toolchain
because the filenames prevented the incorrect build constraints for
other platforms from being acted on.
Change-Id: Iaee5b60a7496166f23fc36319abe07c7a7ec04e5
Reviewed-on: https://go-review.googlesource.com/32311
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Let's Encrypt apparently implements authorization revocation as specified
in the v3 of the spec:
https://tools.ietf.org/html/draft-ietf-acme-acme-03#section-6.4.2.
See the relevant boulder source code here:
be01ca17d3/wfe/wfe.go (L1177-L1213)
This change makes RevokeAuthorization compatible with both v2 and v3
versions of the spec, as well as Let's Encrypt staging/production
actual implementation.
Change-Id: I7e860944005a55b156a45d96e1b8eb41126ce6bb
Reviewed-on: https://go-review.googlesource.com/31990
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rather than change the value of R13 during the execution, keep R13 fixed
(after the initial prelude) and always use offsets from it.
This should help the runtime figure out what's going on if, say, a
signal should occur while running this code.
I've also trimmed the set of saved registers since Go doesn't require
the callee to maintain anything except R10 and R13.
Change-Id: Ifbeca73c1d964cc43bb7f8c20c61066f22fd562d
Reviewed-on: https://go-review.googlesource.com/31717
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This adds use* flags for all arches so a common test can observe what
implementations are supported and test all supported implementations.
Change-Id: I0497b91294ed99309074ac4614ac996e006630c5
Reviewed-on: https://go-review.googlesource.com/31714
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
This adds use* flags for all arches so a common test can observe what
implementations are supported and test all supported implementations.
Change-Id: Icc9c3c1d15626e95f0446493b7fa3159bbe9567d
Reviewed-on: https://go-review.googlesource.com/31712
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
The frame is actually 16 bytes plus alignment, not 0.
This fixes the build on Go 1.6.
Change-Id: Id3dcf4e1628791ed55a38a819dcf3c11ecc2f488
Reviewed-on: https://go-review.googlesource.com/31711
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Now that the frame sizes of these functions are correct, the compiler
is detecting that they overflow the NOSPLIT stack. They don't need to
be NOSPLIT, so remove that flag.
This fixes the 1.7 build. The build is not broken at tip because the
stack guard is larger.
Change-Id: Ie32779c819f63b27ec0a77a44b7d20ee2d550843
Reviewed-on: https://go-review.googlesource.com/31667
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
keccakF1600 manually subtracts 200 from SP, but the generated prologue
already does this and the extra subtraction just means keccakF1600 is
defeating the stack growth check.
Remove the unnecessary SP adjustment.
Change-Id: I9450f6b12489bcd20e9ace30f9dd3066025d3a1a
Reviewed-on: https://go-review.googlesource.com/31653
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
SP offsets were adjusted to fill in the now unused callee save area
using the following Python script:
import sys, re
def adj(m):
delta = int(m.group(1))
if delta >= 408:
delta -= (408 - 352)
return "%d(SP)" % delta
sys.stdout.write(re.sub(r"(\d+)\(SP\)", adj, sys.stdin.read()))
Change-Id: I06675a75d89e5834f804df595868fe4bb8976719
Reviewed-on: https://go-review.googlesource.com/31587
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
The spadj computation in the assembler can't handle SP alignment code
and will just get confused by how it's currently written. Do the
alignment in a scratch register to hide it from the assembler.
Change-Id: I8857f428d96717db29e3a56050f2381bd86807c6
Reviewed-on: https://go-review.googlesource.com/31586
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
Similar to the previous commit, blake2b's assembly routines claim they
have a zero byte frame and manually subtract a frame from the SP,
which can fail to grow the stack when necessary, leading to memory
corruption.
Fix this by using the correct stack frame sizes so the generated stack
growth prologue is correct, and aligning the SP up instead of down.
Change-Id: Ic426338c45c94a2c01d549860c2295a0ee9200be
Reviewed-on: https://go-review.googlesource.com/31585
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
Currently blake2s's assembly routines claim they have a zero byte
frame and manually subtract upwards of 704 bytes from the stack
pointer without cooperating with Go's ABI. As a result, these
functions may not grow the stack when necessary, leading to memory
corruption.
Fix this by using the correct stack frame sizes so the generated stack
growth prologue is correct, and aligning the SP up instead of down.
Change-Id: Ic426338c45c94a2c01d549860c2295a0ee9200bf
Reviewed-on: https://go-review.googlesource.com/31583
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
Reviewed-by: Minux Ma <minux@golang.org>
The assembly implementations of ladderstep and mul contain register
save prologues that are unnecessary in Go because there are no callee
save registers in the Go ABI. Remove these prologues, update all SP
offsets, and reduce the frame size accordingly.
The SP offsets were updated with:
python -c 'import sys, re; sys.stdout.write(re.sub(r"(\d+)\(SP\)", lambda m: "%d(SP)" % (int(m.group(1))-YYY), sys.stdin.read()))'
where YYY was 64 for mul_amd64.s and 56 for ladderstep_amd64.s.
Change-Id: I728948809f479b1c061cc65167dadad651efab31
Reviewed-on: https://go-review.googlesource.com/31580
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
The curve25519 assembly routines do very non-Go-ABI SP adjustments.
These would thoroughly confuse traceback if it were to fire in one of
these functions (say, because of a signal). Plus, we're about to make
the assembler track SP balance through more operations (which it
should have done all along), and the SP alignment performed by these
functions is going to make the assembler think the SP is out of
balance.
Fix this by eliminating the SP alignment prologue from all four
assembly functions. They don't do any operations that care about SP
alignment, so this is simply unnecessary. square and freeze don't even
use the stack for anything other that saving what were presumably
"callee save" registers in some other ABI, so for these we can
eliminate the stack frame entirely.
Change-Id: If9dbb2fb6800d9cd733daa91f483eb2937e95f0f
Reviewed-on: https://go-review.googlesource.com/31579
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
5f31782cfb added build constraints to
disable assembly for Go 1.6 but didn't add the needed tags to the ARM
files. Also, it's not clear that was needed as the error given in
golang/go#17424 only complains about the chacha20poly1305 package.
This change reenables the assembly for Go 1.6 in the poly1305 package.
Tested with 1.6.3 and 1.5.4.
Fixesgolang/go#17512.
Change-Id: I81b41f8810437ea327b415542402cd8ff5c8a390
Reviewed-on: https://go-review.googlesource.com/31492
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Up till now, sum_arm.s was working only because of luck. It was written
assuming that it had stack space below the current stack pointer, but Go
decrements the stack pointer in the function prelude, so it was just
writing off the end of the stack.
This change fixes the stack manipulation so that it only writes within
the bounds.
Fixesgolang/go#17499.
Change-Id: I1951b3344c21f6bd6ade79da8b96dd1bb68180db
Reviewed-on: https://go-review.googlesource.com/31443
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The names of the constant values were previously not scoped to the
package and |andMask| could collide with the variable of the same name
in the AES-GCM assembly.
Change-Id: I9387a6cace71a585ad2fe2afcc8436d44bde0917
Reviewed-on: https://go-review.googlesource.com/31265
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The ARM assembly doesn't work for NaCl on ARM because it doesn't meet
the required rules. This change disables it on ARM and also fixes the
issue that the build constraints in sum_arm.s would be ignored because
they came after the #include.
Change-Id: I6cb3815ec62ac4686a6e72f405af104293586bb6
Reviewed-on: https://go-review.googlesource.com/31264
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The SSE code of chacha20poly1305 used PINSRB and PEXTRQ, which are only available
on machines supporting SSE4.1.
Fixesgolang/go#17464
Change-Id: Ic7313433cb21f9a3709d23b50ab58ac1d87957af
Reviewed-on: https://go-review.googlesource.com/31187
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds a package, chacha20poly1305, which implements the
ChaCha20-Poly1305 AEAD from RFC 7539. This AEAD has several attractive
features:
1. It's naturally constant time. AES-GCM needs either dedicated
hardware or extreme effort to be fast and constant-time, while
this design is easy to make constant-time.
2. It's fast on modern processors: it runs at 1GB/s on my IvyBrige
system.
3. It's seeing significant use in TLS. (A change for crypto/tls is
forthcoming.)
This change merges two CLs:
https://go-review.googlesource.com/#/c/24717https://go-review.googlesource.com/#/c/26691
I took the amd64-optimised AEAD implementation from the former because
it was significantly faster. But the structure of the change is taken
from the latter.
This version will be checked into x/crypto. This package will then be
vendored into the stdlib so that it can be used from crypto/tls.
Change-Id: I5a60587958b7afeec81ca1091e603a7e8517000b
Reviewed-on: https://go-review.googlesource.com/30728
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since the wrapper files are called sum_𝑥.go, it makes sense that the
assembly files would be named similarly.
Change-Id: I5c515008b86c7fedd04b940d7846b84dfccdba33
Reviewed-on: https://go-review.googlesource.com/30727
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change updates the Poly1305 code in x/crypto to reflect some
comments from the review of
https://go-review.googlesource.com/cl/29245/.
Following this change, poly1305_arm.s will be renamed to sum_arm.s, to
match the other files here. (The review becomes confusing if that's done
in the same change as the asmfmt changes.)
Change-Id: Iddf43615eba97c975adb135aef3a814a37e9ec02
Reviewed-on: https://go-review.googlesource.com/30820
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
Previously this code bounded the values to [1, p-1]. This protects
against invalid values that could take lots of CPU time to calculate
with. But the standard bounding is [2, p-2] so mirror that.
Since the DH exchange is signed anyway, this is not a security fix.
Change-Id: Ibef01805a596a433b0699d7a09c076344fa8c070
Reviewed-on: https://go-review.googlesource.com/30590
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change add a function select to correct response from a responder
that includes multiple certificates in the case the server uses response
pre-generation.
RFC6960 section 4.2.2 states:
"The response MUST include a SingleResponse for each certificate in
the request. The response SHOULD NOT include any additional
SingleResponse elements, but, for example, OCSP responders that
pre-generate status responses might include additional SingleResponse
elements if necessary to improve response pre-generation performance
or cache efficiency (according to [RFC5019], Section 2.2.1)."
Change-Id: I39eeaa3daf16a7d7eb030e34229f16cf4295f9d7
Reviewed-on: https://go-review.googlesource.com/10611
Reviewed-by: Russ Cox <rsc@golang.org>
Tests that Marshaling a parsed response
returns the same bytes as were parsed.
Use Marshal in CreateRequest;
still passes CreateRequest's golden test.
Change-Id: I427ef8372d7b62c43b7718d7d90631d022377d32
Reviewed-on: https://go-review.googlesource.com/19488
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This adds support for crypto.Signer-based RSA and ECDSA private keys.
This enables using opaque signing keys as explained in the documentation
for crypto.Signer.
The support is in the form of a new NewSignerPrivateKey function which
makes a PrivateKey from a crypto.Signer.
Fixesgolang/go#15841.
Change-Id: Ice2ec2793a9f5409a5bfd4e5e49d919e14ede1e0
Reviewed-on: https://go-review.googlesource.com/23802
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
When implemented by ssh.PublicKey types, the new CryptoPublicKey
interface exposes the public key in the the crypto.PublicKey form via a
CryptoPublicKey() method.
This is useful for example in a custom ServerConfig.PublicKeyCallback
function to check or record additional details about the underlying
crypto.PublicKey
Change-Id: I4429df42c6fc5119f7c0023a539aaa9c59648bba
Reviewed-on: https://go-review.googlesource.com/23974
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The RequestPty function takes the size arguments in the order height,
then width, instead of the more common width, then height. 80 is a very
common width for a terminal, so when the example reads RequestPty(...,
80, 40, ...), it's easy to assume that the order is width-height.
Switching the order should make it more obvious what is going on.
Change-Id: I1d6266b1c0dcde5ee6e31a6d26d2dcaf14fec58a
Reviewed-on: https://go-review.googlesource.com/18290
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
After discussion around an example SFTP implementation:
https://github.com/pkg/sftp/pull/54
it has been suggested that errors should be handled using
log.Fatal rather than panic, and that the actual underlying error
should also be logged. In the existing SSH examples there
are several different styles of error handling using both panic
and log.Fatalf.
This patch uses log.Fatal consistently for all of these cases.
Change-Id: I2cebfae1821530dc3c5bbc46d451fe026bed582f
Reviewed-on: https://go-review.googlesource.com/16736
Reviewed-by: Russ Cox <rsc@golang.org>
Add the conditional subtraction of 3 from 'h2' (register R10).
Change-Id: I75615b0375f050a5cd97b968075c2992ccd1dee7
Reviewed-on: https://go-review.googlesource.com/30101
Reviewed-by: Adam Langley <agl@golang.org>
RSA and DSA keys if encrypted have the
phrase ENCRYPTED in their Proc-Type block
header according to RFC 1421 Section 4.6.1.1.
This CL checks for that phrase and errors out
if we encounter it, since we don't yet have
decryption of encrypted private keys.
Fixesgolang/go#6650
Change-Id: I5b157716a2f93557d289af5f62994234a2e7a0ed
Reviewed-on: https://go-review.googlesource.com/29676
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If a key is added to an agent keyring with constraints, honor them.
This will remove keys when they've been on the keyring for
LifetimeSecs seconds or longer and will ask the user to confirm a
signing operation if ConfirmBeforeUse is set.
Change-Id: I633713c5f78b13a628a5d752f11b306b6e16a2ef
Reviewed-on: https://go-review.googlesource.com/28956
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the initial key exchange, a client has the option of sending a
guessed key exchange packet. This guess is considered wrong (RFC 4253
Section 7) if "the kex algorithm and/or the host key algorithm is
guessed wrong (server and client have different preferred algorithm),
or if any of the other algorithms cannot be agreed upon...".
The library should be checking the first algorithm in the supported
algorithms, not the agreed algorithm. It also needs to check both the
kex algorithm and the host key algorithm.
Fixesgolang/go#16962
Change-Id: I6b62b1f5b39731326280571d373635085135a2a1
Reviewed-on: https://go-review.googlesource.com/28750
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If no key is provided in the *acme.Client, one is generated, but it
is not cached. This means that every restart of the server process
will use a new account.
This change caches the account key, if one is generated, so that
restarts of the server process use the same key.
Change-Id: I80f127b2cc79745a854b220b8918724ca228e87a
Reviewed-on: https://go-review.googlesource.com/28980
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Vaghin <ddos@google.com>
Say the user wants to create a NewEntity, then Serialize the private and public
keys. Then call Encrypt. The Hash used first for Encrypt will be `RIPEMD160`,
which is not compiled in by default. So say they _specifically_ pass
crypto.SHA256 as the Default hash to NewEntity, this should set the
PreferredHash in the SelfSignature so they can be encrypted with that hash.
Related to golang/go#12153
Change-Id: I3d89f9d60f9abb29ec8365f81da38b8cd0594587
Reviewed-on: https://go-review.googlesource.com/23209
Reviewed-by: Adam Langley <agl@golang.org>
NIST published a Keccak Code Package following the SHA-3 workshop
organized in 2014, containing optimized versions of various Keccak
functions for various architectures. This CL converts the GNU asm
code of the Keccak permutation for the x86_64 architecture into Go
assembly.
The code here is almost an identical copy of KeccakF1600_StatePermute,
with the only modification of converting the input state into the
implementation's internal representation and vice versa before return.
This keeps the algorithm an in-place version and avoids requiring
extra external state inits and data XORs before and after the permute.
The speed difference is:
benchmark old ns/op new ns/op delta
BenchmarkPermutationFunction-8 476 411 -13.66%
BenchmarkSha3_512_MTU-8 9910 8681 -12.40%
BenchmarkSha3_384_MTU-8 7124 6249 -12.28%
BenchmarkSha3_256_MTU-8 5666 4986 -12.00%
BenchmarkSha3_224_MTU-8 5401 4750 -12.05%
BenchmarkShake128_MTU-8 4614 3980 -13.74%
BenchmarkShake256_MTU-8 4935 4295 -12.97%
BenchmarkShake256_16x-8 71850 63798 -11.21%
BenchmarkShake256_1MiB-8 3784244 3285733 -13.17%
BenchmarkSha3_512_1MiB-8 7098875 6163359 -13.18%
benchmark old MB/s new MB/s speedup
BenchmarkPermutationFunction-8 420.11 486.35 1.16x
BenchmarkSha3_512_MTU-8 136.22 155.51 1.14x
BenchmarkSha3_384_MTU-8 189.49 216.03 1.14x
BenchmarkSha3_256_MTU-8 238.23 270.71 1.14x
BenchmarkSha3_224_MTU-8 249.91 284.19 1.14x
BenchmarkShake128_MTU-8 292.58 339.15 1.16x
BenchmarkShake256_MTU-8 273.53 314.28 1.15x
BenchmarkShake256_16x-8 228.03 256.81 1.13x
BenchmarkShake256_1MiB-8 277.09 319.13 1.15x
BenchmarkSha3_512_1MiB-8 147.71 170.13 1.15x
For further details, please see:
- http://csrc.nist.gov/groups/ST/hash/sha-3/Aug2014/documents/vanassche_keccak_code.pdf
- https://github.com/gvanas/KeccakCodePackage
Change-Id: I5b0b9395bba7d8c9acfe2b9c79f6e9c2cf858c7c
Reviewed-on: https://go-review.googlesource.com/17962
Reviewed-by: Adam Langley <agl@golang.org>
Alex Vaghin
Adam Langley
Austin Clements
Andreas Auernhammer
Brad Fitzpatrick
Dmitry Savintsev
Paul van Brouwershaven
Roland Shoemaker
Samuele Pedroni
Martin Garton
Henrik Hodne
Emmanuel Odeke
Mike Houston
Fazal Majid
Alok Menghrajani
Peter Moody
Kaleb Elwert
Jonathan Rudenberg
Jessica Frazelle
Péter Szilágyi