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
The heuristics for BitLen of a product of randomly generated primes
are wrong, and the generated candidates never match the required
size for nprimes > 10. This corner case is not expected to be used in
practice.
R=agl
CC=golang-dev
https://golang.org/cl/7397052
If a test can be placed in the same package ("internal"), it is placed
there. This facilitates testing of package-private details. Because of
dependency cycles some packages cannot be tested by internal tests.
R=golang-dev, rsc, mikioh.mikioh
CC=golang-dev, r
https://golang.org/cl/7323044
Subject Alternative Names in X.509 certificates may include IP
addresses. This change adds support for marshaling, unmarshaling and
verifying this form of SAN.
It also causes IP addresses to only be checked against IP SANs,
rather than against hostnames as was previously the case. This
reflects RFC 6125.
Fixes#4658.
R=golang-dev, mikioh.mikioh, bradfitz
CC=golang-dev
https://golang.org/cl/7336046
On Windows, CryptoAPI is finding an alternative validation path. Since
this is a little non-deterministic, this change disables that test
when using system validation.
R=golang-dev
CC=golang-dev
https://golang.org/cl/7313068
By default, crypto/x509 assumes that users wish to validate
certificates for ServerAuth. However, due to historical reasons,
COMODO's intermediates don't specify ServerAuth as an allowed key
usage.
Rather NSS and CryptoAPI both allow these SGC OIDs to be equivalent to
ServerAuth.
R=rsc
CC=golang-dev
https://golang.org/cl/7312070
Someone found software that generates negative numbers for the RSA
modulus in an X.509 certificate. Our error messages were very poor in
this case so this change improves that.
Update #4728
Return more helpful errors when RSA parameters are negative or zero.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7228072
On Windows, crypto/x509 passes through to Windows's CryptoAPI
to verify certificate chains. This method can't produce a
SystemRootsError, so make sure we always skip the test on
Windows.
This is needed because testVerify is called in both
TestGoVerify and TestSystemVerify on Windows - one is for
testing the Go verifier, the other one is for testing the
CryptoAPI verifier. The orignal CL tried to sidestep
this issue by setting systemSkip to true, but that only
affected TestSystemVerify.
R=golang-dev, agl, snaury, minux.ma
CC=golang-dev
https://golang.org/cl/7185043
