Chiebot-Mirror/boringssl - boringssl - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
David Benjamin	671ccb1a98	Make EVP_PKEY__tls_encodedpoint work with EVP_PKEY_EC. Some third-party code requires it. For now, I've just introduced a new hook on the method table. This is rather goofy though. First, making EVP know about TLS is a layering violation that OpenSSL introduced. They've since fixed this and added EVP_PKEY_get1_encoded_public_key in OpenSSL 3.0, but callers expect the TLS one to exist in OpenSSL 1.1.1, so implement that one. Along the way, implement EC_KEY_oct2key from upstream, which is slightly less tedious when you're already working in EC_KEY. To make this third-party code work (and to write a test without dipping out of EVP, or using the very tedious EVP_PKEY_paramgen API), we also need to change EVP_PKEY_copy_parameters to work when the source EVP_PKEY is empty, per upstream's 2986ecdc08016de978f1134315623778420b51e5. OpenSSL's API has multiple* levels of empty states to worry about! Something to avoid when we get to rethinking this error-prone API. Bug: b:238920520 Change-Id: I3fd99be560db313c1bf549a4e46ffccc31e746e1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54905 Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>	2 years ago
David Benjamin	2e295b91a3	Stub out DSA paramgen functions. We don't support DSA EVP_PKEY_CTXs (trying to create one will just fail), but to aid building projects that try to create them, add the functions and make them always fail. In particular, Node calls these two. It calls EVP_PKEY_CTX_set_dsa_paramgen_q_bits via EVP_PKEY_CTX_ctrl, but I'll send them a patch to use the wrapper function. Change-Id: Ic134c50b6ea0b59dc8f15be77243b9ae9dfa6a61 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54310 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>	3 years ago
David Benjamin	d27a01eb90	Get the EVP_PKEY_METHOD from EVP_PKEY_ASN1_METHOD. This split in methods probably needs rearranging. This means most callers (i.e. ones that don't use EVP_PKEY_CTX_new_id) will no longer pick up the HKDF EVP method. Bug: 497 Change-Id: I72ef255a472c458e8db62461f7b3ac65fa488535 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52830 Reviewed-by: Adam Langley <agl@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>	5 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