In the event that code tries to use a hash function that isn't compiled
in and panics, give the developer a fighting chance of figuring out
which hash function it needed.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12420045
This patch introduces specialized functions for initial
and final permutations, and precomputes the output of the
third permutation on the S-box elements.
benchmark old ns/op new ns/op delta
BenchmarkEncrypt 3581 1226 -65.76%
BenchmarkDecrypt 3590 1224 -65.91%
benchmark old MB/s new MB/s speedup
BenchmarkEncrypt 2.23 6.52 2.92x
BenchmarkDecrypt 2.23 6.53 2.93x
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/12072045
An ARM version of md5block.go with a big improvement in
throughput (up to 2.5x) and a reduction in object size (21%).
Code size
Before 3100 bytes
After 2424 bytes
21% smaller
Benchmarks on Rasperry Pi
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 11703 6636 -43.30%
BenchmarkHash1K 38057 21881 -42.50%
BenchmarkHash8K 208131 142735 -31.42%
BenchmarkHash8BytesUnaligned 11457 6570 -42.66%
BenchmarkHash1KUnaligned 69334 26841 -61.29%
BenchmarkHash8KUnaligned 455120 182223 -59.96%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 0.68 1.21 1.78x
BenchmarkHash1K 26.91 46.80 1.74x
BenchmarkHash8K 39.36 57.39 1.46x
BenchmarkHash8BytesUnaligned 0.70 1.22 1.74x
BenchmarkHash1KUnaligned 14.77 38.15 2.58x
BenchmarkHash8KUnaligned 18.00 44.96 2.50x
benchmark old allocs new allocs delta
BenchmarkHash8Bytes 1 0 -100.00%
BenchmarkHash1K 2 0 -100.00%
BenchmarkHash8K 2 0 -100.00%
BenchmarkHash8BytesUnaligned 1 0 -100.00%
BenchmarkHash1KUnaligned 2 0 -100.00%
BenchmarkHash8KUnaligned 2 0 -100.00%
benchmark old bytes new bytes delta
BenchmarkHash8Bytes 64 0 -100.00%
BenchmarkHash1K 128 0 -100.00%
BenchmarkHash8K 128 0 -100.00%
BenchmarkHash8BytesUnaligned 64 0 -100.00%
BenchmarkHash1KUnaligned 128 0 -100.00%
BenchmarkHash8KUnaligned 128 0 -100.00%
This also adds another test which makes sure that the sums
over larger blocks work properly. I wrote this test when I was
worried about memory corruption.
R=golang-dev, dave, bradfitz, rsc, ajstarks
CC=golang-dev, minux.ma, remyoudompheng
https://golang.org/cl/11648043
Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11699043
Add support for ECDHE-ECDSA (RFC4492), which uses an ephemeral server
key pair to perform ECDH with ECDSA signatures. Like ECDHE-RSA,
ECDHE-ECDSA also provides PFS.
R=agl
CC=golang-dev
https://golang.org/cl/7006047
This does not include AES-GCM yet. Also, it assumes that the handshake and
certificate signature hash are always SHA-256, which is true of the ciphersuites
that we currently support.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10762044
Also use 2048-bit RSA keys as default in generate_cert.go,
as recommended by the NIST.
R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/10676043
On my 64-bit machine, despite being 32-bit code, fixed-base
multiplications are 7.1x faster and arbitary multiplications are 2.6x
faster.
It is difficult to review this change. However, the code is essentially
the same as code that has been open-sourced in Chromium. There it has
been successfully performing P-256 operations for several months on
many machines so the arithmetic of the code should be sound.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10551044
Makes it easy to ask the simple question, what is the hash of this data?
Also fix the commentary and prints in Sum256.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10630043
Makes it easy to ask the simple question, what is the hash of this data?
Also mark block as non-escaping.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10624044
The compiler still gets the escape analysis wrong, but the annotation here is correct.
R=golang-dev, dave, bradfitz
CC=golang-dev
https://golang.org/cl/10514046
TLS clients send ciphersuites in preference order (most prefereable
first). This change alters the order so that ECDHE comes before plain
RSA, and RC4 comes before AES (because of the Lucky13 attack).
This is unlikely to have much effect: as a server, the code uses the
client's ciphersuite order by default and, as a client, the non-Go
server probably imposes its order.
R=golang-dev, r, raggi, jsing
CC=golang-dev
https://golang.org/cl/10372045
Don't panic when the underlying Writer isn't a Closer. And
document what Close does and clarify that it's not a Flush.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10310043
The first identifier in an Object Identifer must be between 0 and 2
inclusive. The range of values that the second one can take depends
on the value of the first one.
The two first identifiers are not necessarily encoded in a single octet,
but in a varint.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10140046
The significant change between TLS 1.0 and 1.1 is the addition of an explicit IV in the case of CBC encrypted records. Support for TLS 1.1 is needed in order to support TLS 1.2.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7880043
Currently we only check the leaf node's issuer against the list of
distinguished names in the server's CertificateRequest message. This
will fail if the client certiciate has more than one certificate in
the path and the leaf node issuer isn't in the list of distinguished
names, but the issuer's issuer was in the distinguished names.
R=agl, agl
CC=gobot, golang-dev
https://golang.org/cl/9795043
crypto/x509 has ended up with a variety of error formats. This change makes them all start with "x509: ".
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9736043
This change contains an implementation of the RSASSA-PSS signature
algorithm described in RFC 3447.
R=agl, agl
CC=gobot, golang-dev, r
https://golang.org/cl/9438043
This isn't clearly a bug on Go's part, but it triggers a bug in Firefox
which means that crypto/tls and net/http cannot be wired up together
unless NextProtos includes "http/1.1". When net/http sets up the
tls.Config, it does this and so works fine. But anyone setting up the
tls.Config themselves will hit the Firefox bug.
Fixes#5445.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/9539045
Failures caused by errors like invalid signatures or missing hash
functions cause rather generic, unhelpful error messages because no
trust chain can be constructed: "x509: certificate signed by unknown
authority."
With this change, authority errors may contain the reason why an
arbitary candidate step in the chain was rejected. For example, in the
event of a missing hash function the error looks like:
x509: certificate signed by unknown authority (possibly because of
"crypto/x509: cannot verify signature: algorithm unimplemented" while
trying to verify candidate authority certificate 'Thawte SGC CA')
Fixes 5058.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9104051
A test added in b37d2fdcc4d9 didn't work with some values of GOMAXPROCS
because the defer statements were in the wrong order: the Pipe could be
closed before the TLS Client was.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/9187047
The PKCS#1 spec requires that the PS padding in an RSA message be at
least 8 bytes long. We were not previously checking this. This isn't
important in the most common situation (session key encryption), but
the impact is unclear in other cases.
This change enforces the specified minimum size.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/9222045
OpenSSL can be configured to send empty records in order to randomise
the CBC IV. This is an early version of 1/n-1 record splitting (that Go
does) and is quite reasonable, but it results in tls.Conn.Read
returning (0, nil).
This change ignores up to 100 consecutive, empty records to avoid
returning (0, nil) to callers.
Fixes 5309.
R=golang-dev, r, minux.ma
CC=golang-dev
https://golang.org/cl/8852044
At some point in the past, I believe the GCD algorithm was setting d to
be negative. The RSA code has been correcting that ever since but, now,
it appears to have changed and the correction isn't needed.
Having d be too large is harmless, it's just a little odd and I
happened to notice.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7948044
XOR key into data 128 bits at a time instead of 64 bits
and pipeline half of state loads. Rotate loop to allow
single-register indexing for state[i].
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 412 224 -45.63%
BenchmarkRC4_1K 3179 1613 -49.26%
BenchmarkRC4_8K 25223 12545 -50.26%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 310.51 570.42 1.84x
BenchmarkRC4_1K 322.09 634.48 1.97x
BenchmarkRC4_8K 320.97 645.32 2.01x
For comparison, on the same machine, openssl 0.9.8r reports
its rc4 speed as somewhat under 350 MB/s for both 1K and 8K
(it is operating 64 bits at a time).
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 418 259 -38.04%
BenchmarkRC4_1K 3200 1884 -41.12%
BenchmarkRC4_8K 25173 14529 -42.28%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 306.04 492.48 1.61x
BenchmarkRC4_1K 319.93 543.26 1.70x
BenchmarkRC4_8K 321.61 557.20 1.73x
For comparison, on the same machine, openssl 1.0.1
reports its rc4 speed as 587 MB/s for 1K and 601 MB/s for 8K.
R=agl
CC=golang-dev
https://golang.org/cl/7865046
-- amd64 --
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 470 421 -10.43%
BenchmarkRC4_1K 3123 3275 +4.87%
BenchmarkRC4_8K 26351 25866 -1.84%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 272.22 303.40 1.11x
BenchmarkRC4_1K 327.80 312.58 0.95x
BenchmarkRC4_8K 307.24 313.00 1.02x
For comparison, on the same machine, openssl 0.9.8r reports
its rc4 speed as somewhat under 350 MB/s for both 1K and 8K.
The Core i5 performance can be boosted another 20%, but only
by making the Xeon performance significantly slower.
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 774 417 -46.12%
BenchmarkRC4_1K 6121 3200 -47.72%
BenchmarkRC4_8K 48394 25151 -48.03%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 165.18 306.84 1.86x
BenchmarkRC4_1K 167.28 319.92 1.91x
BenchmarkRC4_8K 167.29 321.89 1.92x
For comparison, on the same machine, openssl 1.0.1
(which uses a different implementation than 0.9.8r)
reports its rc4 speed as 587 MB/s for 1K and 601 MB/s for 8K.
It is using SIMD instructions to do more in parallel.
So there's still some improvement to be had, but even so,
this is almost 2x faster than what it replaced.
-- 386 --
On a MacBookPro10,2 (Core i5):
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 3491 421 -87.94%
BenchmarkRC4_1K 28063 3205 -88.58%
BenchmarkRC4_8K 220392 25228 -88.55%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 36.66 303.81 8.29x
BenchmarkRC4_1K 36.49 319.42 8.75x
BenchmarkRC4_8K 36.73 320.90 8.74x
On an Intel Xeon E5520:
benchmark old ns/op new ns/op delta
BenchmarkRC4_128 2268 524 -76.90%
BenchmarkRC4_1K 18161 4137 -77.22%
BenchmarkRC4_8K 142396 32350 -77.28%
benchmark old MB/s new MB/s speedup
BenchmarkRC4_128 56.42 244.13 4.33x
BenchmarkRC4_1K 56.38 247.46 4.39x
BenchmarkRC4_8K 56.86 250.26 4.40x
R=agl
CC=golang-dev
https://golang.org/cl/7547050