delta/go-git.git/src/crypto/aes, branch dev.inline

crypto/{cipher,tls,internal/cryptohw}: prioritise AES-GCM when hardware support is present.

2016-11-07T20:01:18+00:00

Support for ChaCha20-Poly1305 ciphers was recently added to crypto/tls.
These ciphers are preferable in software, but they cannot beat hardware
support for AES-GCM, if present.

This change moves detection for hardware AES-GCM support into
cipher/internal/cipherhw so that it can be used from crypto/tls. Then,
when AES-GCM hardware is present, the AES-GCM cipher suites are
prioritised by default in crypto/tls. (Some servers, such as Google,
respect the client's preference between AES-GCM and ChaCha20-Poly1305.)

Fixes #17779.

Change-Id: I50de2be486f0b0b8052c4628d3e3205a1d54a646
Reviewed-on: https://go-review.googlesource.com/32871
Run-TryBot: Adam Langley 
Reviewed-by: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

all: update s390x assembly to use vet-friendly names

2016-11-03T15:04:44+00:00

No functional changes.

Change-Id: Ibf592c04be506a76577d48574e84ab20c3238b49
Reviewed-on: https://go-review.googlesource.com/32589
Run-TryBot: Josh Bleecher Snyder 
TryBot-Result: Gobot Gobot 
Reviewed-by: Michael Munday

crypto/{aes,cipher}: fix panic in CBC on s390x when src length is 0

2016-10-13T21:42:23+00:00

Adds a test to check that block cipher modes accept a zero-length
input.

Fixes #17435.

Change-Id: Ie093c4cdff756b5c2dcb79342e167b3de5622389
Reviewed-on: https://go-review.googlesource.com/31070
Run-TryBot: Michael Munday 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick

crypto/{aes,cipher}: add optimized implementation of AES-GCM for s390x

2016-10-05T15:37:53+00:00

Also adds two tests: one to exercise the counter incrementing code
and one which checks the output of the optimized implementation
against that of the generic implementation for large/unaligned data
sizes.

Uses the KIMD instruction for GHASH and the KMCTR instruction for AES
in counter mode.

AESGCMSeal1K  75.0MB/s ± 2%  1008.7MB/s ± 1%  +1245.71%  (p=0.000 n=10+10)
AESGCMOpen1K  75.3MB/s ± 1%  1006.0MB/s ± 1%  +1235.59%   (p=0.000 n=10+9)
AESGCMSeal8K  78.5MB/s ± 1%  1748.4MB/s ± 1%  +2127.34%   (p=0.000 n=9+10)
AESGCMOpen8K  78.5MB/s ± 0%  1752.7MB/s ± 0%  +2134.07%   (p=0.000 n=10+9)

Change-Id: I88dbcfcb5988104bfd290ae15a60a2721c1338be
Reviewed-on: https://go-review.googlesource.com/30361
Reviewed-by: Brad Fitzpatrick 
Run-TryBot: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

crypto/cipher: enforce message size limits for GCM.

2016-09-02T16:23:15+00:00

The maximum input plaintext for GCM is 64GiB - 64. Since the GCM
interface is one-shot, it's very hard to hit this in Go (one would need
a 64GiB buffer in memory), but we should still enforce this limit.

Thanks to Quan Nguyen for pointing it out.

Change-Id: Icced47bf8d4d5dfbefa165cf13e893205c9577b8
Reviewed-on: https://go-review.googlesource.com/28410
Run-TryBot: Adam Langley 
TryBot-Result: Gobot Gobot 
Reviewed-by: Andrew Gerrand

crypto/cipher, crypto/aes: add s390x implementation of AES-CTR

2016-04-29T21:17:31+00:00

This commit adds the new 'ctrAble' interface to the crypto/cipher
package. The role of ctrAble is the same as gcmAble but for CTR
instead of GCM. It allows block ciphers to provide optimized CTR
implementations.

The primary benefit of adding CTR support to the s390x AES
implementation is that it allows us to encrypt the counter values
in bulk, giving the cipher message instruction a larger chunk of
data to work on per invocation.

The xorBytes assembly is necessary because xorBytes becomes a
bottleneck when CTR is done in this way. Hopefully it will be
possible to remove this once s390x has migrated to the ssa
backend.

name      old speed     new speed     delta
AESCTR1K  160MB/s ± 6%  867MB/s ± 0%  +442.42%  (p=0.000 n=9+10)

Change-Id: I1ae16b0ce0e2641d2bdc7d7eabc94dd35f6e9318
Reviewed-on: https://go-review.googlesource.com/22195
Reviewed-by: Adam Langley

crypto/cipher, crypto/aes: add s390x implementation of AES-CBC

2016-04-29T21:17:09+00:00

This commit adds the cbcEncAble and cbcDecAble interfaces that
can be implemented by block ciphers that support an optimized
implementation of CBC. This is similar to what is done for GCM
with the gcmAble interface.

The cbcEncAble, cbcDecAble and gcmAble interfaces all now have
tests to ensure they are detected correctly in the cipher
package.

name             old speed     new speed      delta
AESCBCEncrypt1K  152MB/s ± 1%  1362MB/s ± 0%  +795.59%   (p=0.000 n=10+9)
AESCBCDecrypt1K  143MB/s ± 1%  1362MB/s ± 0%  +853.00%   (p=0.000 n=10+9)

Change-Id: I715f686ab3686b189a3dac02f86001178fa60580
Reviewed-on: https://go-review.googlesource.com/22523
Run-TryBot: Michael Munday 
TryBot-Result: Gobot Gobot 
Reviewed-by: Adam Langley

crypto/aes: use asm for BenchmarkExpand on amd64

2016-04-22T18:58:29+00:00

This reverses the change to this benchmark made in 9b6bf20.

Change-Id: I79ab88286c3028d3be561957140375bbc413e7ab
Reviewed-on: https://go-review.googlesource.com/22340
Run-TryBot: Michael Munday 
TryBot-Result: Gobot Gobot 
Reviewed-by: Minux Ma

crypto/aes: add s390x assembly implementation

2016-04-20T17:02:14+00:00

Adds support for single block encryption using the cipher message
(KM) instruction. KM handles key expansion internally and
therefore it is not done up front when using the assembly
implementation on s390x.

Change-Id: I69954b8ae36d549e1dc40d7acd5a10bedfaaef9c
Reviewed-on: https://go-review.googlesource.com/22194
Run-TryBot: Michael Munday 
TryBot-Result: Gobot Gobot 
Reviewed-by: Bill O'Farrell 
Reviewed-by: Brad Fitzpatrick

crypto/aes: de-couple asm and go implementations

2016-04-19T18:50:51+00:00

There is currently only one assembly implementation of AES
(amd64). While it is possible to fit other implementations to the
same pattern it complicates the code. For example s390x does not
use expanded keys, so having enc and dec in the aesCipher struct
is confusing.

By separating out the asm implementations we can more closely
match the data structures to the underlying implementation. This
also opens the door for AES implementations that support block
cipher modes other than GCM (e.g. CTR and CBC).

This commit changes BenchmarkExpandKey to test the go
implementation of key expansion. It might be better to have some
sort of 'initialisation' benchmark instead to cover the startup
costs of the assembly implementations (which might be doing
key expansion in a different way, or not at all).

Change-Id: I094a7176b5bbe2177df73163a9c0b711a61c12d6
Reviewed-on: https://go-review.googlesource.com/22193
Run-TryBot: Michael Munday 
TryBot-Result: Gobot Gobot 
Reviewed-by: Brad Fitzpatrick