tree 751fab8b67cda40bacbe836948ac6cca56a0b587
parent aa8d29dbd1eca56888ca07fc954124ebd270653a
author armfazh <armfazh@cloudflare.com> 1540227597 -0700
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1540837587 +0000

Fix EVP_tls_cbc_digest_record is slow using SHA-384 and short messages

Symptom: When using larger hash functions and short messages,
these six blocks take too much time to be conditionally copied.

Observations:
 - SHA-384 consumes more data per iteration, unlike SHA-256.
 - The value of `kVarianceBlocks` must depend on the parameters
   of the selected hash algorithm.
 - Avoid magic constants.

Changes:
 - A new formula for the kVarianceBlocks value.
 - Stronger test vectors were created in change: 32724.
 - The new formula passes these tests.

Discussion:
 OpenSSL team: https://github.com/openssl/openssl/pull/7342
 Quoting mattcaswell:
> The "real" data that needs to be hashed has to be padded for the
> hashing algorithm. For SHA1 the smallest amount of padding that
> can be added is the "0x80" byte plus 8 bytes containing the message
> length, i.e. 9 bytes. If the data length is within 9 bytes of the
> end of the hash block boundary then the padding will push it into
> an extra block to be hashed.

Change-Id: Id1ad2389927014316eed2b453aac6e4c2a585c5c
Reviewed-on: https://boringssl-review.googlesource.com/c/32624
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>