Change-Id: I9246c8228d38559c40e69fa403fa946ac1b31dbe
Change-Id: I34877ac1d6d7fe9ffa7eabe46b4032af84d33794 Reviewed-on: https://go-review.googlesource.com/c/153337 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Ia8ddd4e52dcfe87f9daef2edd37c8155fcae7f5a
Change-Id: I4063d5ec4ac45561b94472b528583be564981912 Reviewed-on: https://go-review.googlesource.com/120144 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Conflicts due to randutil.MaybeReadByte (kept at the top for patch maintainability and consistency): src/crypto/ecdsa/ecdsa.go src/crypto/rsa/pkcs1v15.go src/crypto/rsa/rsa.go Change-Id: I03a2de541e68a1bbdc48590ad7c01fbffbbf4a2b
Code has ended up depending on things like RSA's key generation being deterministic given a fixed random Reader. This was never guaranteed and would prevent us from ever changing anything about it. This change makes certain calls randomly (based on the internal fastrand) read an extra byte from the random Reader. This helps to ensure that code does not depend on internal details. I've not added this call in the key generation of ECDSA and DSA because, in those cases, key generation is so obvious that it probably is acceptable to do the obvious thing and not worry about code that depends on that. This does not affect tests that use a Reader of constant bytes (e.g. a zeroReader) because shifting such a stream is a no-op. The stdlib uses this internally (which is fine because it can be atomically updated if the crypto libraries change). It is possible that external tests could be doing the same and would thus break if we ever, say, tweaked the way RSA key generation worked. I feel that addressing that would be more effort than it's worth. Fixes #21915 Change-Id: I84cff2e249acc921ad6eb5527171e02e6d39c530 Reviewed-on: https://go-review.googlesource.com/64451 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Each URL was manually verified to ensure it did not serve up incorrect content. Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df Reviewed-on: https://go-review.googlesource.com/115798 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
This is a git merge of master into dev.boringcrypto. The branch was previously based on release-branch.go1.9, so there are a handful of spurious conflicts that would also arise if trying to merge master into release-branch.go1.9 (which we never do). Those have all been resolved by taking the original file from master, discarding any Go 1.9-specific edits. all.bash passes on darwin/amd64, which is to say without actually using BoringCrypto. Go 1.10-related fixes to BoringCrypto itself will be in a followup CL. This CL is just the merge. Change-Id: I4c97711fec0fb86761913dcde28d25c001246c35
This is inspired by https://blog.cloudflare.com/go-dont-collect-my-garbage/ This CL adds allocation tracking and parallelizes p256-related benchmarks. Amount of allocations can be significantly reduced by marking amd64 asm functions as noescape. This exposes a bug in p256MovCond: PANDN with memory argument will fault if memory is not aligned, so they are replaced with MOVDQU (which is ok with unaligned memory) and register version of PANDN. Results on 88-thread machine (2x 22 cores) below: crypto/elliptic: name old time/op new time/op delta BaseMultP256-88 1.50µs ±11% 1.19µs ± 5% -20.20% (p=0.000 n=10+10) ScalarMultP256-88 5.47µs ± 5% 3.63µs ±10% -33.66% (p=0.000 n=9+10) name old alloc/op new alloc/op delta BaseMultP256-88 800B ± 0% 288B ± 0% -64.00% (p=0.000 n=10+10) ScalarMultP256-88 2.59kB ± 0% 0.26kB ± 0% -90.12% (p=0.000 n=10+10) name old allocs/op new allocs/op delta BaseMultP256-88 13.0 ± 0% 6.0 ± 0% -53.85% (p=0.000 n=10+10) ScalarMultP256-88 16.0 ± 0% 5.0 ± 0% -68.75% (p=0.000 n=10+10) crypto/ecdsa: name old time/op new time/op delta SignP256-88 8.63µs ±37% 7.55µs ±38% ~ (p=0.393 n=10+10) VerifyP256-88 13.9µs ± 8% 7.0µs ± 7% -49.29% (p=0.000 n=10+9) KeyGeneration-88 2.77µs ±11% 2.34µs ±11% -15.57% (p=0.000 n=10+10) name old alloc/op new alloc/op delta SignP256-88 4.14kB ± 1% 2.98kB ± 2% -27.94% (p=0.000 n=10+10) VerifyP256-88 4.47kB ± 0% 0.99kB ± 0% -77.84% (p=0.000 n=9+10) KeyGeneration-88 1.21kB ± 0% 0.69kB ± 0% -42.78% (p=0.000 n=10+10) name old allocs/op new allocs/op delta SignP256-88 47.0 ± 0% 34.0 ± 0% -27.66% (p=0.000 n=10+10) VerifyP256-88 38.0 ± 0% 17.0 ± 0% -55.26% (p=0.000 n=10+10) KeyGeneration-88 20.0 ± 0% 13.0 ± 0% -35.00% (p=0.000 n=10+10) On machine with only 4 cores, results are much less impressive: around 2% performance gain. Change-Id: I8a2f8168f83d27ad9ace1b4b1a1e11cb83edf717 Reviewed-on: https://go-review.googlesource.com/80757 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
The crypto.Signer interface takes pre-hased messages for ECDSA and RSA, but the argument in the implementations was called “msg”, not “digest”, which is confusing. This change renames them to help clarify the intended use. Change-Id: Ie2fb8753ca5280e493810d211c7c66223f94af88 Reviewed-on: https://go-review.googlesource.com/70950 Reviewed-by: Filippo Valsorda <hi@filippo.io>