Tag:
Branch:
Tree:
9d64d8d237
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
dependabot/go_modules/golang.org/x/net-0.23.0
esni
fips-20180730
fips-20220613
fips-20230428
fips-20240407
fips-android-20191008
grpc-202302
infra/config
main-with-bazel
master
master-with-bazel
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 }
1 Commits (9d64d8d2373db494d3460102b970f4aaf92ee274)
Author | SHA1 | Message | Date |
---|---|---|---|
Benjamin Brittain | 8d8d8f3ea7 |
Generates "low-level" bindings for Rust using bindgen
This is designed to be the minimal infrastructure required to support using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen is used to generate Rust bindings in lockstep with the rest of the build. `rust-openssl` can consume these generated bindings with minimal changes. Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645 Reviewed-by: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> |
3 years ago |
David Benjamin | 9372f38cd0 |
Bound RSA and DSA key sizes better.
Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@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> |
4 years ago |