aes: add GCM-TLS checks and improve performance

[qmuntal]

This PR can be reviewed commit by commit.

There are two main changes:

• First commit: Long story short, it adds some security checks to AES-GCM Seal method when sealing a TLS payload. I've added a new document with the detailed description of why we weren't implementing those checks before and how we are implementing them now.
• Following commits: While investigating the missing checks issue I noticed that Go, OpenSSL and BoringSSL have highly optimized routines for AES-GCM, but we were just doing the bare minimum. Doing a quick web search one can find many reports, such as this one, showing that AES-GCM accounts for almost 95% of all TLS 1.2 and 1.3 traffic. So it is a no-brainer to optimize it as much as reasonable.
  This I what I did:
  • Reuse the same cipher context in all the Go aesGCM lifetime, which reduces cgo calls and helps reusing OpenSSL cipher context backing memory buffers.
  • Batch all Seal/Open cgo calls into one, which means going from 5 calls to 1.

And the results speak by themselves:

name           old time/op    new time/op     delta
AESGCM_Open-4    1.92µs ± 4%     0.40µs ± 7%   -78.92%  (p=0.000 n=10+10)
AESGCM_Seal-4    1.89µs ± 2%     0.41µs ± 4%   -78.49%  (p=0.000 n=9+10)

name           old speed      new speed       delta
AESGCM_Open-4  33.4MB/s ± 4%  158.4MB/s ± 6%  +374.66%  (p=0.000 n=10+10)
AESGCM_Seal-4  33.9MB/s ± 2%  157.7MB/s ± 4%  +365.16%  (p=0.000 n=9+10)

name           old B/op       new B/op        delta
AESGCM_Open-4     48.0B ± 0%       0.0B       -100.00%  (p=0.000 n=10+10)
AESGCM_Seal-4     48.0B ± 0%       0.0B       -100.00%  (p=0.000 n=10+10)

name           old allocs/op  new allocs/op   delta
AESGCM_Open-4      4.00 ± 0%       0.00       -100.00%  (p=0.000 n=10+10)
AESGCM_Seal-4      4.00 ± 0%       0.00       -100.00%  (p=0.000 n=10+10)

[dagood]

Reviewed doc, mostly small suggestions. Agree with the Resolution part, for sure seems like the most reasonable way to go!

[dagood]

Are there any tests to make sure bad nonces are properly caught in the Go standard library test suite?

[qmuntal]

There are no explicit tests that verifies IVs construction follows the 800-38D 8.3 spec.

Still, Go's IV generation currently follows that spec, and there are some tests in crypto/tls (the ones starting with TestHandshake*) that compare TLS flows against prerecorded golden flows, so if there is an unintentional change in the IV generation algorithm, all those tests will fail.

I'll try to submit a test upstream that directly covers the IV generation so our expectations don't rely on a catch-all regression test nor in dev.boringcrypto tests.

[qmuntal]

I'll try to submit a test upstream that directly covers the IV generation so our expectations don't rely on a catch-all regression test nor in dev.boringcrypto tests.

Here it is: https://go-review.googlesource.com/c/go/+/391495