boringssl

860 Commits

61 Branches

23 Tags

511 MiB

Tag: Branch: Tree: f8f97bfcbb

Commit Graph

Author	SHA1	Message	Date
David Benjamin	03cae7a2b3	Keep EVP_CIPHER/EVP_MD lookup and do_all functions in sync Node seems uncommonly sensitive to this, so let's write these functions in a way that stays in sync and test this. See also https://boringssl-review.googlesource.com/c/boringssl/+/49585 This does incur a cost across all BoringSSL consumers that use these functions: as a result of Node indiscriminately exposing every cipher, we end up pulling more and more ciphers into these getters. But that ship sailed long ago, so, instead, document that EVP_get_cipherby* should not be used by size-conscious callers. EVP_get_digestby* probably should have the same warning, but I've left it alone for now because we don't quite have the same proliferation of digests as ciphers. (Though there are things in there, like MD4, that ought to be better disconnected.) Change-Id: I61ca406c146279bd05a52bed6c57200d1619c5da Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49625 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>	4 years ago
David Benjamin	669ffe64a4	Simplify the Lucky13 mitigation. Rather than computing kVarianceBlocks, which is hard to reason about, use a sha1_final_with_secret_suffix abstraction. This lets us separate reasoning in bytes about the minimum and maximum values of \|data_size\| and the interaction with HMAC, separately from the core constant-time SHA-1 update. It's also faster. I'm guessing it's the more accurate block counts. Before: Did 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec) Did 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec) Did 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec) Did 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec) Did 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec) After: Did 2089000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000049us (16.7 MB/sec) [+141.3%] Did 851000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000034us (108.9 MB/sec) [+38.2%] Did 553000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002169us (372.9 MB/sec) [+28.1%] Did 178000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2008596us (726.0 MB/sec) [+20.1%] Did 98000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2001509us (802.2 MB/sec) [+18.6%] Confirmed with valgrind tooling that this is still constant-time. In doing so, I ran into a new nuisance with GCC. In loops where we run constant_time_lt with a counter value, GCC sometimes offsets the loop counter by the secret. It cancels it out before dereferencing memory, etc., but valgrind does not know that x + uninit - uninit = x and gets upset. I've worked around this with a barrier for now. Change-Id: Ieff8d2cad1b56c07999002e67ce4e6d6aa59e0d3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46686 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago

Author

SHA1

Message

Date

David Benjamin

03cae7a2b3

Keep EVP_CIPHER/EVP_MD lookup and do_all functions in sync

Node seems uncommonly sensitive to this, so let's write these functions
in a way that stays in sync and test this. See also
https://boringssl-review.googlesource.com/c/boringssl/+/49585

This does incur a cost across all BoringSSL consumers that use these
functions: as a result of Node indiscriminately exposing every cipher,
we end up pulling more and more ciphers into these getters. But that
ship sailed long ago, so, instead, document that EVP_get_cipherby*
should not be used by size-conscious callers.

EVP_get_digestby* probably should have the same warning, but I've left
it alone for now because we don't quite have the same proliferation of
digests as ciphers. (Though there are things in there, like MD4, that
ought to be better disconnected.)

Change-Id: I61ca406c146279bd05a52bed6c57200d1619c5da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>

4 years ago

David Benjamin

669ffe64a4

Simplify the Lucky13 mitigation.

Rather than computing kVarianceBlocks, which is hard to reason about,
use a sha1_final_with_secret_suffix abstraction. This lets us separate
reasoning in bytes about the minimum and maximum values of |data_size|
and the interaction with HMAC, separately from the core constant-time
SHA-1 update.

It's also faster. I'm guessing it's the more accurate block counts.

Before:
Did 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec)
Did 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec)
Did 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec)
Did 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec)
Did 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec)

After:
Did 2089000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000049us (16.7 MB/sec) [+141.3%]
Did 851000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000034us (108.9 MB/sec) [+38.2%]
Did 553000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002169us (372.9 MB/sec) [+28.1%]
Did 178000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2008596us (726.0 MB/sec) [+20.1%]
Did 98000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2001509us (802.2 MB/sec) [+18.6%]

Confirmed with valgrind tooling that this is still constant-time. In
doing so, I ran into a new nuisance with GCC. In loops where we run
constant_time_lt with a counter value, GCC sometimes offsets the loop
counter by the secret. It cancels it out before dereferencing memory,
etc., but valgrind does not know that x + uninit - uninit = x and gets
upset. I've worked around this with a barrier for now.

Change-Id: Ieff8d2cad1b56c07999002e67ce4e6d6aa59e0d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46686
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

4 years ago

Adam Langley

fb0c05cac2

acvp: add CMAC-AES support.

Change by Dan Janni.

Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

5 years ago

3 Commits (f8f97bfcbb97c8bd14c4cb6942dd7b0c492cb3e0)