-- 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
Previously, Go TLS servers always took the client's preferences into
account when selecting a ciphersuite. This change adds the option of
using the server's preferences, which can be expressed by setting
tls.Config.CipherSuites.
This mirrors Apache's SSLHonorCipherOrder directive.
R=golang-dev, nightlyone, bradfitz, ality
CC=golang-dev
https://golang.org/cl/7163043
I messed this up from the beginning. The receiver isn't a pointer so
setting Err is useless. In order to maintain the API, just remove the
superfluous code.
Fixes#4657.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7161043
bytes.Equal is simpler to read and should also be faster because
of short-circuiting and assembly implementations.
Change generated automatically using:
gofmt -r 'bytes.Compare(a, b) == 0 -> bytes.Equal(a, b)'
gofmt -r 'bytes.Compare(a, b) != 0 -> !bytes.Equal(a, b)'
R=golang-dev, dave, adg, rsc
CC=golang-dev
https://golang.org/cl/7038051
While half of all numbers don't have their most-significant bit set,
this is becoming increasingly impermissible for RSA moduli. In an
attempt to exclude weak keys, several bits of software either do, or
will, enforce that RSA moduli are >= 1024-bits.
However, Go often generates 1023-bit RSA moduli which this software
would then reject.
This change causes crypto/rsa to regenerate the primes in the event
that the result is shorter than requested.
It also alters crypto/rand in order to remove the performance impact
of this:
The most important change to crypto/rand is that it will now set the
top two bits in a generated prime (OpenSSL does the same thing).
Multiplying two n/2 bit numbers, where each have the top two bits set,
will always result in an n-bit product. (The effectively makes the
crypto/rsa change moot, but that seems too fragile to depend on.)
Also this change adds code to crypto/rand to rapidly eliminate some
obviously composite numbers and reduce the number of Miller-Rabin
tests needed to generate a prime.
R=rsc, minux.ma
CC=golang-dev
https://golang.org/cl/7002050
EDE2 is a rare DES mode that can be implemented with crypto/des, but
it's somewhat non-obvious so this CL adds an example of doing so.
Fixes#3537.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/6721056
Add support for loading X.509 key pairs that consist of a certificate
with an EC public key and its corresponding EC private key.
R=agl
CC=golang-dev
https://golang.org/cl/6776043
Arbitrary decisions: order of the arguments and the
fact it takes a block-type argument (rather than
leaving to user to fill it in later); I'm happy whatever
colour we want to paint it.
We also change DecryptPEMBlock so that it won't
panic when the IV has the wrong size.
R=agl, agl
CC=golang-dev
https://golang.org/cl/6820114
The current implement can fail when the
block size is not a multiple of 8 bytes.
This CL makes it work, and also checks that the
data is in fact a multiple of the block size.
R=agl, agl
CC=golang-dev
https://golang.org/cl/6827058
The RFC doesn't actually have an opinion on whether this is a fatal or
warning level alert, but common practice suggests that it should be a
warning.
This involves rebasing most of the tests.
Fixes#3413.
R=golang-dev, shanemhansen, rsc
CC=golang-dev
https://golang.org/cl/6654050
I was an idiot and was thinking that a small base didn't matter
because the exponentiation would quickly make the number the same size
as the modulus. But, of course, the small base continues to make
multiplications unrealistically cheap throughout the computation.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/6649048
It was suggested that it's too easy to use crypto/hmac insecurely and
I think that has some merit. This change adds a Equal function to
make it obvious that MAC values should be compared in constant time.
R=rsc, max
CC=golang-dev
https://golang.org/cl/6632044
Preparation for forthcoming CL 6624051: Will make it
easier to see if/what changes are incurred by it.
The alignment changes in this CL are due to CL 6610051
(fix to alignment heuristic) where it appears that an
old version of gofmt was run (and thus the correct
alignment updates were not done).
R=r
CC=golang-dev
https://golang.org/cl/6639044
I typoed the code and tried to parse all the way to the end of the
message. Therefore it fails when NPN is not the last extension in the
ServerHello.
Fixes#4088.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6637052
Adds a DecryptBlock function which takes a password and a *pem.Block and
returns the decrypted DER bytes suitable for passing into other crypto/x509
functions.
R=golang-dev, agl, leterip
CC=golang-dev
https://golang.org/cl/6555052
Session resumption saves a round trip and removes the need to perform
the public-key operations of a TLS handshake when both the client and
server support it (which is true of Firefox and Chrome, at least).
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6555051
Previously we tried to parse email constraints as the maximum base
distance (which is unused and must be omitted according to RFC 5280)
because they share the same tag number. Rather than complicate the
code further, this CL just ignores the unused values.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6552044
X509KeyPair wasn't really supposed to allow the certificate and
key to be in the same file, but it did work if you put the key
first. Since some HTTPS servers support loading keys and certs
like this, this change makes it work in either order.
Fixes#3986.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6499103
Right now we only have 32-bit ints so that's a no-op.
Took the opportunity to check for some other invalid values too.
Suggestions for additions or modifications welcome.
R=agl
CC=golang-dev
https://golang.org/cl/6493112
Fixes#3862.
There were many areas where conn.err was being accessed
outside the mutex. This proposal moves the err value to
an embedded struct to make it more obvious when the error
value is being accessed.
As there are no Benchmark tests in this package I cannot
feel confident of the impact of this additional locking,
although most will be uncontended.
R=dvyukov, agl
CC=golang-dev
https://golang.org/cl/6497070
If we aren't explicit about the KeyUsages, the verifier
will treat the certificate as a server certificate and require
it to have a ExtKeyUsageServerAuth key usage.
R=golang-dev
CC=golang-dev
https://golang.org/cl/6453148
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
These aren't needed for scalar multiplication, but since we export a
generic Add function we should handle it.
This change also corrects two bugs in p224Contract that it turned up.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6458076
This removes some (non-short only) tests that involved connections to
the outside world and thus were flakey. This does remove some test
coverage of the root fetchers on non-Windows platforms, but the right
place for that is crypto/x509.
R=golang-dev, krautz, rsc
CC=golang-dev
https://golang.org/cl/6455085
We already support reading ECDSA certificates and this change adds
write support.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6422046
OpenSSL requires that RSA signatures be exactly the same byte-length
as the modulus. Currently it'll reject ~1/256 of our signatures: those
that end up a byte shorter.
Fixes#3796.
R=golang-dev, edsrzf, r
CC=golang-dev
https://golang.org/cl/6352093
Previously, strings that didn't have an explicit ASN.1 string type
were taken to be ASN.1 PrintableStrings. This resulted in an error if
a unrepresentable charactor was included.
For compatibility reasons, I'm too afraid to switch the default string
type to UTF8String, but this patch causes untyped strings to become
UTF8Strings if they contain a charactor that's not valid in a
PrintableString.
Fixes#3791.
R=golang-dev, bradfitz, r, r
CC=golang-dev
https://golang.org/cl/6348074
Entrust have issued a root certificate that's not marked as valid for
signing certificates.
This results in Go programs failing to validate certificates that
chain up to this root (i.e. gateway.push.apple.com:2195).
Although this is clearly a mistake on Entrust's part, it seems that we
will have to bodge around it.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/6346064
Ran 'double.pl' on the pkg tree to identify doubled words.
One change to an error string return in x509; the rest are in comments.
Thanks to Matt Jibson for the idea.
R=golang-dev, bsiegert
CC=golang-dev
https://golang.org/cl/6344089
Flame motivated me to get around to adding extended key usage support
so that code signing certificates can't be used for TLS server
authentication and vice versa.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6304065
The speedup is a combination of unrolling/specializing
the actual code and also making the compiler generate better code.
Go 1.0.1 (size: 1239 code + 320 data = 1559 total)
md5.BenchmarkHash1K 1000000 7178 ns/op 142.64 MB/s
md5.BenchmarkHash8K 200000 56834 ns/op 144.14 MB/s
Partial unroll (size: 1115 code + 256 data = 1371 total)
md5.BenchmarkHash1K 5000000 2513 ns/op 407.37 MB/s
md5.BenchmarkHash8K 500000 19406 ns/op 422.13 MB/s
Complete unroll (size: 1900 code + 0 data = 1900 code)
md5.BenchmarkHash1K 5000000 2442 ns/op 419.18 MB/s
md5.BenchmarkHash8K 500000 18957 ns/op 432.13 MB/s
Comparing Go 1.0.1 and the complete unroll (this CL):
benchmark old MB/s new MB/s speedup
md5.BenchmarkHash1K 142.64 419.18 2.94x
md5.BenchmarkHash8K 144.14 432.13 3.00x
On the same machine, 'openssl speed md5' reports 441 MB/s
and 531 MB/s for our two cases, so this CL is at 90% and 80% of
those speeds, which is at least in the right ballpark.
OpenSSL is using carefully engineered assembly, so we are
unlikely to catch up completely.
Measurements on a Mid-2010 MacPro5,1.
R=golang-dev, bradfitz, agl
CC=golang-dev
https://golang.org/cl/6220046
This includes the NIST test suite for ECDSA and alters the test to
parse and evaluate it.
R=golang-dev, bradfitz, rsc, b
CC=golang-dev
https://golang.org/cl/6219058
http://www.rsa.com/rsalabs/node.asp?id=2125:
NOTE: A new OID has been defined for the combination
of the v1.5 signature scheme and the SHA-224 hash function:
sha224WithRSAEncryption OBJECT IDENTIFIER ::=
Like the other sha*WithRSAEncryption OIDs in PKCS #1 v2.1,
this OID has NULL parameters.
The DigestInfo encoding for SHA-224 (see Section 9.2, Note 1) is:
(0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 04 05 00 04 1c || H
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/6208076
crypto.Hash.New() changed to panicking when the hash function isn't
linked in, but crypto/x509 still expects it to return nil.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6175047
On Solaris versions before Solaris 11, the kernel will not
return more than 1040 on a single read from /dev/urandom.
R=golang-dev, agl, bradfitz, rsc, iant, dchest
CC=golang-dev
https://golang.org/cl/6113046
When SNI based certificate selection is enabled, we previously used
the default private key even if we selected a non-default certificate.
Fixes#3367.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5987058
crypto/tls is tested, in part, by replaying recorded TLS connections
and checking that the bytes sent by the Go code haven't changed.
Previously we used GnuTLS's debug output and extracted the bytes of
the TLS connection using a Python script. That wasn't great, and I
think GnuTLS removed that level of debugging in a more current
release.
This change records the connection with Go code and adds a test for
ECDHE-AES clients generating using this method.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5988048
Previously we checked that de ≡ 1 mod φ(n). Since φ(n) is a multiple
of |(ℤ/nℤ)*|, this encompassed the new check, but it was too strict as
keys generated by GnuTLS would be rejected when gcd(p-1,q-1)≠1.
(Also updated the error strings in crypto/rsa to contain the package name, which some were missing.)
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5867043
The existing code that tried to prevent ECC ciphersuites from being
selected when there were no mutual curves still left |suite| set.
This lead to a panic on a nil pointer when there were no acceptable
ciphersuites at all.
Thanks to George Kadianakis for pointing it out.
R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/5857043
If a CertificateRequest is received we have to reply with a
Certificate message, even if we don't have a certificate to offer.
Fixes#3339.
R=golang-dev, r, ality
CC=golang-dev
https://golang.org/cl/5845067
This moves the various CA root fetchers from crypto/tls into crypto/x509.
The move was brought about by issue 2997. Windows doesn't ship with all
its root certificates, but will instead download them as-needed when using
CryptoAPI for certificate verification.
This CL changes crypto/x509 to verify a certificate using the system root
CAs when VerifyOptions.RootCAs == nil. On Windows, this verification is
now implemented using Windows's CryptoAPI. All other root fetchers are
unchanged, and still use Go's own verification code.
The CL also fixes the hostname matching logic in crypto/tls/tls.go, in
order to be able to test whether hostname mismatches are honored by the
Windows verification code.
The move to crypto/x509 also allows other packages to use the OS-provided
root certificates, instead of hiding them inside the crypto/tls package.
Fixes#2997.
R=agl, golang-dev, alex.brainman, rsc, mikkel
CC=golang-dev
https://golang.org/cl/5700087
An X.509 path length constrains the number of certificate that may
follow in the chain. This is a little simplistic for a first pass as it
doesn't check self-signed certificates (which don't count towards the
length), but it's conservatively simplistic.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5727057
asn1 didn't have an omitempty tag, so the list of additional primes in
an RSA private key was serialised as an empty SEQUENCE, even for
version 1 structures. This tripped up external code that didn't handle
v2.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5729062
Not a Go 1 issue, but appeared to be fairly easy to fix.
- Note that a few existing test cases look slightly worse but
those cases were not representative for real code. All real
code looks better now.
- Manual move of the comment in go/scanner/example_test.go
before applying gofmt.
- gofmt -w $GOROOT/src $GOROOT/misc
Fixes#3062.
R=rsc
CC=golang-dev
https://golang.org/cl/5674093
* add -work option to save temporary files (Fixes issue 2980)
* fix go test -i to work with cgo packages (Fixes issue 2936)
* do not overwrite/remove empty directories or non-object
files during build (Fixes issue 2829)
* remove package main vs package non-main heuristic:
a directory must contain only one package (Fixes issue 2864)
* to make last item workable, ignore +build tags for files
named on command line: go build x.go builds x.go even
if it says // +build ignore.
* add // +build ignore tags to helper programs
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/5674043
1) Remove the Reset() member in crypto/aes and crypto/des (and
document the change).
2) Turn several empty error structures into vars. Any remaining error
structures are either non-empty, or will probably become so in the
future.
3) Implement SetWriteDeadline for TLS sockets. At the moment, the TLS
status cannot be reused after a Write error, which is probably fine
for most uses.
4) Make crypto/aes and crypto/des return a cipher.Block.
R=rsc, r
CC=golang-dev
https://golang.org/cl/5625045
(*Writer, error) if they take a compression level, and *Writer otherwise.
Rename gzip's Compressor and Decompressor to Writer and Reader, similar to
flate and zlib.
Clarify commentary when writing gzip metadata that is not representable
as Latin-1, and fix io.EOF comment bug.
Also refactor gzip_test to be more straightforward.
Fixes#2839.
R=rsc, r, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/5639057
Specifically, remove simply where it is claiming that the
code or the action to be carried out is simple, since the
reader might disagree.
R=golang-dev, bradfitz, gri
CC=golang-dev
https://golang.org/cl/5637048
I missed an overflow in contract because I suspected that the prime
elimination would take care of it. It didn't, and I forgot to get back
to the overflow. Because of this, p224Contract may have produced a
non-minimal representation, causing flakey failures ~0.02% of the
time.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5592045
We support SSLv3 as a server but not as a client (and we don't want to
support it as a client). This change fixes the error message when
connecting to an SSLv3 server since SSLv3 support on the server side
made mutualVersion accept SSLv3.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5545073
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
Also, add an explicit error type when the right hand side is an unexported
function.
R=golang-dev, gri, rogpeppe, agl, rsc
CC=golang-dev
https://golang.org/cl/5564048
This lets the client of go/build specify additional tags that
can be recognized in a // +build directive. For example,
a build for a custom environment like App Engine might
include "appengine" in the BuildTags list, so that packages
can be written with some files saying
// +build appengine (build only on app engine)
or
// +build !appengine (build only when NOT on app engine)
App Engine here is just a hypothetical context. I plan to use
this in the cmd/go sources to distinguish the bootstrap version
of cmd/go (which will not use networking) from the full version
using a custom tag. It might also be useful in App Engine.
Also, delete Build and Script, which we did not end up using for
cmd/go and which never got turned on for real in goinstall.
R=r, adg
CC=golang-dev
https://golang.org/cl/5554079
Remove NewMD5, NewSHA1 and NewSHA256 in favor of using New and
explicitly importing the used hash-function. This way when using, for
example, HMAC with RIPEMD there's no md5, sha1 and sha256 linked in
through the hmac package.
A gofix rule is included, and applied to the standard library (3 files
altered).
This change is the result of a discussion at
https://golang.org/cl/5550043/ to pull the discussion about
deprecating these functions out of that issue.
R=golang-dev, agl
CC=golang-dev, r, rsc
https://golang.org/cl/5556058
(Sending to r because of the API change.)
Over time we might want to add support for other key types.
While I was in the code, I also made the use of RawSubject the same
between Subject and Issuer when creating certificates.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5554049
(Sending to r because of the API change.)
This change alters the API for crypto/elliptic to permit different
implementations in the future. This will allow us to add faster,
constant-time implementations of the standard curves without any more
API changes.
As a demonstration, it also adds a constant-time implementation of
P224. Since it's only 32-bit, it's actually only about 40% the speed
of the generic code on a 64-bit system.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5528088
Previously, a timeout (in int64 nanoseconds) applied to a granularity
even smaller than one operation: a 100 byte read with a 1 second timeout
could take 100 seconds, if the bytes all arrived on the network 1 second
apart. This was confusing.
Rather than making the timeout granularity be per-Read/Write,
this CL makes callers set an absolute deadline (in time.Time)
after which operations will fail. This makes it possible to
set deadlines at higher levels, without knowing exactly how
many read/write operations will happen in e.g. reading an HTTP
request.
Fixes#2723
R=r, rsc, dave
CC=golang-dev
https://golang.org/cl/5555048
First was, apart from adding tests, a single line of code (to add the
constructor function). Adding SHA512-based hashing to crypto/hmac
required minor rework of the package because of a previously hardcoded
block-size in it's implementation. Instead of using a hash.Hash
generator function the constructor function now uses a crypto.Hash
type, which was extended to expose information about block size.
The only standard library package impacted by the change is
crypto/tls, for which the fix is included in this patch. It might be
useful to extend gofix to include this API change too.
R=agl, r, rsc, r
CC=golang-dev
https://golang.org/cl/5550043
1) Include Szabolcs Nagy's patch which adds serialisation for more
signature subpackets.
2) Include Szabolcs Nagy's patch which adds functions for making DSA
keys.
3) Make the random io.Reader an argument to the low-level signature
functions rather than having them use crypto/rand.
4) Rename crypto/openpgp/error to crypto/openpgp/errors so that it
doesn't clash with the new error type.
R=bradfitz, r
CC=golang-dev
https://golang.org/cl/5528044
I didn't believe that OpenPGP allowed > SHA-1 with DSA, but it does and
so we need to perform hash truncation.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5510044
Fix incorrect marshal/unmarshal of certificateRequest.
Add support for configuring client-auth on the server side.
Fix the certificate selection in the client side.
Update generate_cert.go to new time package
Fixes#2521.
R=krautz, agl, bradfitz
CC=golang-dev, mikkel
https://golang.org/cl/5448093
This lets us mark net's cgo_stub.go as only to be
built when cgo is disabled.
R=golang-dev, ality, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/5489100
We still very much assume it in the code, but with this change in
place we can implement other things later without changing and users
of the package.
Fixes#2319.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/5489073
- no empty lines inside empty structs and interfaces
- top-level declarations are separated by a blank line if
a) they are of different kind (e.g. const vs type); or
b) there are documentation comments associated with a
declaration (this is new)
- applied gofmt -w misc src
The actual changes are in go/printer/nodes.go:397-400 (empty structs/interfaces),
and go/printer/printer.go:307-309 (extra line break). The remaining
changes are cleanups w/o changing the existing functionality.
Fixes issue 2570.
R=rsc
CC=golang-dev
https://golang.org/cl/5493057
Made te and td arrays into variables te0-3 and td0-3,
which improves performance from 7000ns/op to 5800.
R=rsc, rogpeppe, agl
CC=golang-dev
https://golang.org/cl/5449077
Although FIPS 186-3 says that we should truncate the hashes, at least
one other library (libgcrypt) doesn't. This means that it's impossible
to interoperate with code using gcrypt if we enforce the truncation
inside of crypto/dsa.
This change shouldn't actually affect anything because nearly
everybody pairs DSA with SHA1, which doesn't need to be truncated in
either case.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5471043
The code in hash functions themselves could write directly into the
output buffer for a savings of about 50ns. But it's a little ugly so I
wasted a copy.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5440111
This avoids a problem when creating certificates with parents that
were produce by other code: the Go structures don't contain all the
information about the various ASN.1 string types etc and so that
information would otherwise be lost.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5453067
All but 3 cases (in gcimporter.go and hixie.go)
are automatic conversions using gofix.
No attempt is made to use the new Append functions
even though there are definitely opportunities.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5447069
By converting array indices to uint8, they are automatically
constrained in the array range, and the binary AND with 0xff
is no longer needed anymore.
Before: aes.BenchmarkEncrypt 363 ns/op
After: aes.BenchmarkEncrypt 273 ns/op
R=golang-dev, gri, agl
CC=golang-dev, remy
https://golang.org/cl/5450084
This is the result of running `gofix -r hashsum` over the tree, changing
the hash function implementations by hand and then fixing a couple of
instances where gofix didn't catch something.
The changed implementations are as simple as possible while still
working: I'm not trying to optimise in this CL.
R=rsc, cw, rogpeppe
CC=golang-dev
https://golang.org/cl/5448065
Previously we were using the map iteration order to set the order of
the cipher suites in the ClientHello.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5440048
- syscall (not os) now defines the Errno type.
- the low-level assembly functions Syscall, Syscall6, and so on
return Errno, not uintptr
- syscall wrappers all return error, not uintptr.
R=golang-dev, mikioh.mikioh, r, alex.brainman
CC=golang-dev
https://golang.org/cl/5372080
alerts get used as both values and errors.
Rather than introduce an alertError wrapper,
this CL just adds an Error method, which will
satisfy the error interface when the time comes.
R=agl, bradfitz
CC=golang-dev
https://golang.org/cl/5294073
Will make gofix for error work better.
There is no other indication in this file that
these are actually error implementations.
(They are only used elsewhere.)
R=bradfitz
CC=golang-dev
https://golang.org/cl/5305068
I found these by adding a check to govet, but the check
produces far too many false positives to be useful.
Even so, these few seem worth cleaning up.
R=golang-dev, bradfitz, iant
CC=golang-dev
https://golang.org/cl/5311067
Although there's still no concrete security reason not to use 3, I
think Bleichenbacher has convinced me that it's a useful defense and
it's what everyone else does.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5307060
tls.Conn.Close() didn't close the underlying connection and tried to
do a handshake in order to send the close notify alert.
http didn't look for errors from the TLS handshake.
Fixes#2281.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5283045
We also have functions for dealing with PKCS#1 private keys. This
change adds functions for PKIX /public/ keys. Most of the time one
won't be parsing them because they usually come in certificates, but
marshaling them happens and I've previously copied the code from
x509.go for this.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5286042
X509 names, like everything else X509, are ludicrously general. This
change keeps the raw version of the subject and issuer around for
matching. Since certificates use a distinguished encoding, comparing
the encoding is the same as comparing the values directly. This came
up recently when parsing the NSS built-in certificates which use the
raw subject and issuer for matching trust records to certificates.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5275047
The following ciphersuites are added:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
This change helps conform to the TLS1.1 standard because
the first ciphersuite is "mandatory" in RFC4346
R=golang-dev, agl, rsc
CC=golang-dev
https://golang.org/cl/5164042
With this in place, a TLS server is capable of selecting the correct
certificate based on the client's ServerNameIndication extension.
The need to call Config.BuildNameToCertificate is unfortunate, but
adding a sync.Once to the Config structure made it uncopyable and I
felt that was too high a price to pay. Parsing the leaf certificates
in each handshake was too inefficient to consider.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5151048
The go/build package already recognizes
system-specific file names like
mycode_darwin.go
mycode_darwin_386.go
mycode_386.s
However, it is also common to write files that
apply to multiple architectures, so a recent CL added
to go/build the ability to process comments
listing a set of conditions for building. For example:
// +build darwin freebsd openbsd/386
says that this file should be compiled only on
OS X, FreeBSD, or 32-bit x86 OpenBSD systems.
These conventions are not yet documented
(hence this long CL description).
This CL adds build comments to the multi-system
files in the core library, a step toward making it
possible to use go/build to build them.
With this change go/build can handle crypto/rand,
exec, net, path/filepath, os/user, and time.
os and syscall need additional adjustments.
R=golang-dev, r, gri, r, gustavo
CC=golang-dev
https://golang.org/cl/5011046
It would be nice not to have to support this since all the clients
that we care about support TLSv1 by now. However, due to buggy
implementations of SSLv3 on the Internet which can't do version
negotiation correctly, browsers will sometimes switch to SSLv3. Since
there's no good way for a browser tell a network problem from a buggy
server, this downgrade can occur even if the server in question is
actually working correctly.
So we need to support SSLv3 for robustness :(
Fixes#1703.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5018045
Weekday is redundant information for a Time structure.
When parsing a time with a weekday specified, it can create an
incorrect Time value.
When parsing a time without a weekday specified, people
expect the weekday to be set.
Fix all three problems by computing the weekday on demand.
This is hard to gofix, since we must change the type of the node.
Since uses are rare and existing code will be caught by the compiler,
there is no gofix module here.
Fixes#2245.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/4974077
It's possible to include a self-signed root certificate as an
intermediate and push Verify into a loop.
I already had a test for this so I thought that it was ok, but it
turns out that the test was void because the Verisign root certificate
doesn't contain the "IsCA" flag and so it wasn't an acceptable
intermediate certificate for that reason.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4657080
In function readSignedMessage a pointer to for loop variable 'key' was incorrectly being assigned
to md.SignedBy. Changed so that md.SignedBy is pointing to the 'more correct' memory position.
R=golang-dev, r, agl
CC=golang-dev
https://golang.org/cl/4631088
This changes Signature so that parsed signatures can be reserialized
exactly. With this ability we can add Serialize to Entity and also the
ability to sign other public keys.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4627084
Each package using struct field tags assumes that
it is the only package storing data in the tag.
This CL adds support in package reflect for sharing
tags between multiple packages. In this scheme, the
tags must be of the form
key:"value" key2:"value2"
(raw strings help when writing that tag in Go source).
reflect.StructField's Tag field now has type StructTag
(a string type), which has method Get(key string) string
that returns the associated value.
Clients of json and xml will need to be updated.
Code that says
type T struct {
X int "name"
}
should become
type T struct {
X int `json:"name"` // or `xml:"name"`
}
Use govet to identify struct tags that need to be changed
to use the new syntax.
R=r, r, dsymonds, bradfitz, kevlar, fvbommel, n13m3y3r
CC=golang-dev
https://golang.org/cl/4645069
