Tag:
Branch:
Tree:
955ef7991e
2214
2272
2311
2357
2490
2564
2623
2661
2704
2785
2883
2924
2987
3029
3071
3112
3202
3239
3282
3359
3538
3945
chromium-2214
chromium-2272
chromium-2311
chromium-2357
chromium-2490
chromium-2564
chromium-2623
chromium-2661
chromium-2704
chromium-2883
chromium-2924
chromium-2987
chromium-3029
chromium-3071
chromium-3112
chromium-3202
chromium-3239
chromium-3282
chromium-3359
chromium-3538
chromium-3945
chromium-5359
chromium-5414
chromium-stable
chromium-stable-with-bazel
esni
fips-20180730
fips-20220613
fips-20230428
fips-20240407
fips-20240805
fips-20250107
fips-android-20191008
grpc-202302
infra/config
main
main-with-bazel
master
master-with-bazel
0.20240913.0
0.20240930.0
0.20241024.0
0.20241203.0
0.20241209.0
0.20250114.0
0.20250212.0
fips-20170615
fips-20180730
fips-20190808
fips-20210429
fips-20220613
fips-android-20191020
version_for_cocoapods_1.0
version_for_cocoapods_10.0
version_for_cocoapods_2.0
version_for_cocoapods_3.0
version_for_cocoapods_4.0
version_for_cocoapods_5.0
version_for_cocoapods_6.0
version_for_cocoapods_7.0
version_for_cocoapods_8.0
version_for_cocoapods_9.0
${ noResults }
3 Commits (955ef7991e41ac6c0ea5114b4b9abb98cc5fd614)
Author | SHA1 | Message | Date |
---|---|---|---|
|
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 |
|
c31fb79cfe |
Simplify tls_cbc.c slightly.
This removes the now unnecessary virtual calls. Benchmark differences are mostly positive but probably noise. Before: Did 839000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000497us (6.7 MB/sec) Did 623000 AES-128-CBC-SHA1 (256 bytes) open operations in 2000409us (79.7 MB/sec) Did 434000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2002909us (292.5 MB/sec) Did 146000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2000785us (597.8 MB/sec) Did 82000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2014268us (667.0 MB/sec) After: Did 866000 AES-128-CBC-SHA1 (16 bytes) open operations in 2000697us (6.9 MB/sec) [+3.2%] Did 616000 AES-128-CBC-SHA1 (256 bytes) open operations in 2001403us (78.8 MB/sec) [-1.2%] Did 432000 AES-128-CBC-SHA1 (1350 bytes) open operations in 2003898us (291.0 MB/sec) [-0.5%] Did 148000 AES-128-CBC-SHA1 (8192 bytes) open operations in 2006042us (604.4 MB/sec) [+1.1%] Did 83000 AES-128-CBC-SHA1 (16384 bytes) open operations in 2010885us (676.3 MB/sec) [+1.4%] Change-Id: I735e99296ca9a1771518c622b8e7e6979a0d30bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46685 Reviewed-by: Adam Langley <agl@google.com> |
4 years ago |
|
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 |