aboutsummaryrefslogtreecommitdiff
path: root/tool
AgeCommit message (Collapse)AuthorFilesLines
8 daysMake BoringSSL initialization-lessDavid Benjamin1-2/+0
Now that we don't depend on external CRYPTO_library_init calls or the static initializer to initialize CPU capabilities, we can drop a ton of code. This makes CRYPTO_library_init, and all its wrappers, into no-ops and drops the (non-FIPS) static initializer. I've added an internal OPENSSL_init_cpuid function for the places where the library actually needs to initialize the CPU vector. Note this slightly changes the default, previously static-initializer-full build: previously, CRYPTO_library_init was a no-op and we relied on the static initializer. Now we uniformly use CRYPTO_once. This should be an atomic read in the steady state and essentially free. We can restore the static initializer by default if this ends up being a problem, but having only one mode is more straightforward. This also avoids problems if an application calls into BoringSSL during its own static initializer. Static initializers are not coherently ordered. Update-Note: The BORINGSSL_NO_STATIC_INITIALIZER build option and CRYPTO_library_init are now unnecessary. Once updating past this revision, those options can now be cleaned up from downstream projects. Fixed: 40644931 Change-Id: Idc2e6ea7a73d6352e0360fd886c46d88dba3568c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69508 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-06-04Mark kyber as experimentalBob Beck1-3/+2
Kyber will be changing once the standardization of ML_KEM is finalized by NIST. Update-Note: The use of Kyber functions from <openssl/experimental/kyber.h> will not compile unless the build using them defines an appropriate preprocessor define. As this interface will change once NIST finalizes the standardization of ML_KEM. Users of this code must be aware, and be prepared to make changes when this happens Change-Id: I159bae38e58dd059b3fcccf69ae9f3d5fb03bd46 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66868 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-05-08Re-apply dilithium and make it work with a limited stackBob Beck1-0/+114
This reverts commit a56407d27da6ebf63ae9817dc19587a0ae98ef4a. On top of this it then makes changes to make dilithium work without consuming excessive stack space.. This makes DILITHIUM_sign and DILITHIUM_generate_key and friends fallible for malloc failures. It removes the abort() calls that were previously present if CBB allocations did not work and rolls them into the malloc failure case. Change-Id: Ibcd70a98bb500c76df8885c0a7d06f8e9f5b18c3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67027 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Guillaume Endignoux <guillaumee@google.com> Reviewed-by: Sophie Schmieg <sschmieg@google.com>
2024-03-21Make it plainly obvious this is experimental code.Bob Beck1-5/+8
Since we are saying this will die when standardized, let us ensure users of this code from this location take notice and action before using it. We then selectively allow it in the speed tool and in our tests. If we like this approach, I'll go back and apply it to kyber (which will have some other fallout consequences to fix) but this one should be painless right now. This can also be applied to Dilithium when it comes back. Future experimentals could be added in this manner. Change-Id: Ie3b41cf16278868562ef1c8b28f2caed5e0e2dd1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66887 Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2024-03-09Revert "Add a Dilithium implementation."Bob Beck1-92/+0
This reverts commit 9b34a3224062c456ff0d0b77fd9a34c5ad08dfea. Sadly this blow's up google3 because of stack usage being higher than google3's limits Change-Id: I8f1493a158e5fcab508593841ac3a37eb8404dcc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66847 Auto-Submit: Bob Beck <bbe@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2024-03-06Add a Dilithium implementation.Guillaume Endignoux1-0/+92
This is a reference implementation, not intended to be optimized, but reasonably efficient to be usable and (best-effort) constant time. Change-Id: I47489b566f65e946edd519aa168aee359d1e9f1a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63685 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2024-03-06Move spx from internal to include/openssl/experimentalBob Beck1-1/+1
Change-Id: I5c8db3bbca774c7f503538b43f79077421574b0f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66487 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2024-02-23Make an include/openssl/experimental. Move kyber to it for now.Bob Beck1-1/+1
Update-Note: <openssl/kyber.h> has moved to <openssl/experimental/kyber.h> Change-Id: I51d37aeb2b6cfbbaae494cc38f1b0a82669d2692 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66467 Reviewed-by: David Benjamin <davidben@google.com> Auto-Submit: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
2023-11-30Always use a 32-byte shared secret for KyberDavid Benjamin1-4/+4
Although the round-3 specification has a variable-length output, the final ML-KEM construction is expected to use a fixed 32-byte output. To simplify the future transition, we apply the same restriction. Update-Note: The Kyber public APIs have changed slightly, but we do not believe there are any users of them yet. Change-Id: Iea4fb1b13ecfcc3fead62989cee79de011f413c5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64349 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-11-01Add basic C implementation of SPHINCS+-SHA2-128s.Stefan Koelbl1-42/+87
The implementation is based on the current round 3 specification with the modifications to FORS indices generation suggest on the mailing list. The implementation passes test vectors and uses the default SHA256 implementation of BoringSSL. Change-Id: Iab2dbaf5f692d490577dc940d9f3e298a72e9193 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60965 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2023-07-11Use constant curve-specific groups whenever possibleDavid Benjamin1-29/+26
Also remove unnecessary EC_GROUP_free calls. EC_GROUP_free is only necessary in codepaths where arbitrary groups are possible. Bug: 20 Change-Id: I3dfb7f07b890ab002ba8a302724d8bc671590cfe Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60932 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-07-11Use std::make_unique when possibleDavid Benjamin4-14/+13
We've required C++14 for a while now. As we're mostly C with a little C++, this is less helpful, but may as well avoid bare new where possible. Change-Id: Icf3386e3f3b6f2092bb0089ed874cc50985f1a40 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61429 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-07-05Use sources.cmake for the bssl toolDavid Benjamin1-23/+0
Bug: 542 Change-Id: I94684f2398a28792cc0a31c8e776eecac8cc3cba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61305 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-06-09Make RSA opaqueDavid Benjamin1-6/+2
Three years of updating calling code are finally complete! Update-Note: Accessing the RSA struct directly is no longer supported. Use accessors instead. Bug: 316, 325 Change-Id: I27b4c9899cb96f5807075b8fe351eaf72a9a9d44 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60610 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2023-05-31Align remaining TLS ECDH APIs on "group" terminologyDavid Benjamin1-3/+3
This adds "group" versions of our codepoint-based APIs. This is mostly because it looks weird to switch terminology randomly in the implementation. See I7a356793d36419fc668364c912ca7b4f5c6c23a2 for additional context. I've not bothered renaming the bssl_shim flags. That seems a waste of time. Change-Id: I566ad132f5a33d99efd8cb2bb8b76d9a6038c825 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60207 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-05-14Add a multi-threaded mode to bssl speedDavid Benjamin1-154/+292
This is inspired somewhat from how https://github.com/google/benchmark's threaded benchmark support works. (It seems to spawn a bunch of threads, latch them all together, and then run.) This adds a TimeFunctionParallel which runs multiple copies of the benchmark in parallel, after waiting for all the threads to synchronize. Some functions had to be tweaked so they don't write to a single, shared output buffer. This probably could use some improvement. In playing with it, the numbers are pretty unstable. We also don't currently benchmark anything that captures EVP's internal refcounts. But hopefully it's enough to get a start. I am able to measure impacts from the PRNG locks at least. Bug: 570 Change-Id: I92c29a05ba082fc45701afd6f0effe23f7b148bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59845 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com>
2023-05-04Rename EC_RAW_POINT to EC_JACOBIANDavid Benjamin1-2/+2
EC_RAW_POINT is a confusing name. It's mostly about whether this is stack-allocated EC_POINT without the EC_GROUP pointer. Now that we have EC_AFFINE, EC_JACOBIAN captures what it's doing a bit better. Fixed: 326 Change-Id: I5b71a387e899a94c79be8cd5e0b54b8432f7d5da Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59565 Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2023-03-30Adding a C implementation of Kyber.Sophie Schmieg1-3/+55
Passes test vectors, and should be constant time, but is currently not optimized and neither the API nor the standard is stable. Change-Id: I89b90877e023a43ee7238e11b86065444ab3bdec Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57845 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>
2023-02-14Remove global_target from build.David Benjamin1-1/+0
This was added with the generated symbol-prefixing header. But it seems to be sufficient for crypto to have a dependency on the generated header, along with some of the stray bits of delocate. It's a little unclear from CMake documentation how these are processed; normally .o files can be built before libraries are built or linked, only the link step depends on. But, empirically, if A links B, and B has a dependency on C, then CMake seems to run C before building any of A. I tested this by making a small project where the generation step slept for three seconds and running with enough parallelism that we'd have tripped. Interestingly, in the Makefile output, the individual object file targets didn't have that dependency, but the target itself did. But this was true on both A and B, so I think that just might not work. Also fix the dependency in the custom target. The old formulation broke when using an absolute path to the symbols file. Change-Id: I2053d44949f907d465da403a5ec69c191740268f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56928 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-14Don't include custom builds of libc++ in CMake installsDavid Benjamin1-1/+1
Also stick the very verbose default install directory in a variable so we don't have to repeat it everywhere. Change-Id: I1a6a85c4d42d3a6e766e52b2d0ecd8e81c6ed4e3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56607 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-14Specify -Iinclude with the crypto target.David Benjamin1-2/+0
It's unclear to me whether doing it target-by-target is an improvement in crypto/fipsmodule, but this otherwise does seem a bit tidier. This aligns with CMake's documentation and "modern CMake" which prefers this pattern. Change-Id: I36c81842bff8b36eeaaf5dd3e0695fb45f3376c9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56585 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2023-02-14Implement P256_XMD:SHA-256_SSWU_RO_ and P384_XMD:SHA-384_SSWU_RO_David Benjamin1-6/+20
Also add public APIs for this, now that the specification is no longer expected to change, and because a project external to the library wishes to use it. For now, I've kept the P-256 version using the generic felem_exp, but we should update that to use the specialized field arithmetic. Trust Tokens will presumably move to this later and, in the meantime, another team wants this. Bug: chromium:1414562 Change-Id: Ie38203b4439ff55659c4fb2070f45d524c55aa2a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57147 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Steven Valdez <svaldez@google.com>
2023-02-07Trim unnecessary -lrt and ws2_32 deps in the build.David Benjamin1-16/+1
The ws2_32 dependency comes from BIO, which is in libcrypto. Once it's added there, it should get inherited by anything downstream, so we don't need to keep listing it. We also no longer need -lrt. We tried to remove it in https://boringssl-review.googlesource.com/4622, but had to revert it in https://boringssl-review.googlesource.com/4894 because of clock_gettime. clock_gettime, per the Linux man page, is now in libc, not librt, as of glibc 2.17. THat was released December 2012, well past our five year watermark, so clean this part of the build up. Change-Id: Ie6a07434b0cb02fe916b32ab8c326ec33d40bcb6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56606 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-01-27Remove old Trust Token redeem API.Steven Valdez1-31/+10
This removes TRUST_TOKEN_ISSUER_redeem and renames TRUST_TOKEN_ISSUER_redeem_raw to TRUST_TOKEN_ISSUER_redeem. Change-Id: Ifc07c73a6827ea21b5f2b0469d4bed4d9bf8fa84 Update-Note: Callers of TRUST_TOKEN_ISSUER_redeem_raw should remove the _raw. Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56365 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Auto-Submit: Steven Valdez <svaldez@google.com>
2023-01-17Const-correct sk_FOO_deep_copy's copy callback.David Benjamin1-3/+3
This aligns with upstream OpenSSL, so it's hopefully more compatible. Code search says no one outside of the project uses this function, so it's unlikely to break anyone. Whether it makes things better is a bit of a wash: OBJ_dup and OPENSSL_strdup loose a pointless wrapper. X509_NAME_dup gains one, but hopefully that can be resolved once we solve the X509_NAME const-correctness problem. CRYPTO_BUFFER_up_ref gains one... really FOO_up_ref should have type const T * -> T *, but OpenSSL decided it returns int, so we've got to cast. Change-Id: Ifa6eaf26777ac7239db6021fc1eafcaed98e42c4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56032 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-12-03Switch microsecond and iteration counts in bssl speed to uint64_t.David Benjamin1-26/+28
We were mixing uint64_t and unsigned, which flagged -Wshorten-64-to-32. While I'm here, switch the iteration count to uint64_t to cut down on uses of 'unsigned'. While we have no real risk of overflow a u32 here, counting the number of times we perform some operation in a loop would probably best be u64. (I'm guessing we originally used unsigned mostly so that %u worked. But PRIu64 exists, though it's wordy.) Bug: 516 Change-Id: I6abc24ecb029c2c223bb940c903d497868bab9fc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55455 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-11-21Replace malloc/memcpy pairs with memdup.David Benjamin1-6/+2
Change-Id: Icc56ceb3f27be3c02aeb6a169b044c7846f1ce97 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55268 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-11-14More -Wshorten-64-to-32 fixes.David Benjamin1-1/+1
I had a rewrite of the decrepit ciphers (CAST and Blowfish) to use CRYPTO_{load,store}_u32_be and drop the old macros, but this is probably not worth the effort to review. Instead, just fix the type in the macro. Bug: 516 Change-Id: I1cdecc16f6108a6235f90cf9c2198bc797c6716e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54985 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-04-26Fix build for older CMake versions.Daniel Thornburgh1-1/+1
CMake versions newer than ~3.1x automatically determine the subdirectory under CMAKE_INSTALL_PREFIX using the type of the installed target. Older versions need this to be manually computed using the GNUInstallDirs library. Since we override the CMAKE_INSTALL_PREFIX default, this just controls the internal layout of the install/ directory generated underneath the boringssl checkout. Bug: 488 Change-Id: I97b02006301e463bb0cfd54acb2b27656484cc85 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52345 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2022-04-21[build] Fix build with HEAD clang.Daniel Thornburgh1-2/+0
The HEAD version of Clang fails to build boringssl due to the following warning triggered at -Werror: /usr/local/google/home/dthorn/curl/boringssl/tool/digest.cc:229:12: error: variable 'bad_hash_lines' set but not used This change removes the variable. Change-Id: I25009925d9a2dfc5b1783accab19e4b861db4ec2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52265 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2022-04-14Add CMake install rules.Daniel Thornburgh1-0/+1
This creates an install directory under the top level source directory. The install contains a CMake config file that produces variables and targets compatible with FindOpenSSL, or the directory can be scanned by FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with third-party dependencies that find an SSL implementation via CMake. Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2022-02-22Include the EKU extension in bssl server's self-signed certs.David Benjamin1-14/+30
macOS requires an explicit EKU extension. This fixes connection failing with ERR_CERT_INVALID in Chrome (when the built-in verifier isn't enabled). https://support.apple.com/en-us/HT210176 Change-Id: Ida23391107fe0168a854c1f4ea3ac52db670e7e8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51525 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2022-01-24Switch CRYPTO_BUFFER_POOL to SipHash-2-4.David Benjamin1-5/+30
This hash table, in applications that use pooling, can dedup received certificates in memory and thus should use a keyed hash. Change-Id: Idc40dc8f7463025183121642b30ea0de43ebac0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51125 Reviewed-by: Adam Langley <agl@google.com>
2021-12-15Fix the easy -Wformat-signedness errors.David Benjamin1-3/+3
GCC has a warning that complains about even more type mismatches in printf. Some of these are a bit messy and will be fixed in separate CLs. This covers the easy ones. The .*s stuff is unfortunate, but printf has no size_t-clean string printer. ALPN protocol lengths are bound by uint8_t, so it doesn't really matter. The IPv6 printing one is obnoxious and arguably a false positive. It's really a C language flaw: all types smaller than int get converted to int when you do arithmetic. So something like this first doesn't overflow the shift because it computes over int, but then the result overall is stored as an int. uint8_t a, b; (a << 8) | b On the one hand, this fixes a "missing" cast to uint16_t before the shift. At the same time, the incorrect final type means passing it to %x, which expects unsigned int. The compiler has forgotten this value actually fits in uint16_t and flags a warning. Mitigate this by storing in a uint16_t first. The story doesn't quite end here. Arguments passed to variadic functions go through integer promotion[0], so the argument is still passed to snprintf as an int! But then va_arg allows for a signedness mismatch[1], provided the value is representable in both types. The combination means that %x, though actually paired with unsigned, also accept uint8_t and uint16_t, because those are guaranteed to promote to an int that meets [1]. GCC recognizes [1] applies here. (There's also PRI16x, but that's a bit tedious to use and, in glibc, is defined as plain "x" anyway.) [0] https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions [1] https://en.cppreference.com/w/c/variadic/va_arg Bug: 450 Change-Id: Ic1d41356755a18ab922956dd2e07b560470341f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50765 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2021-09-22Speed up constant-time base64 decoding.David Benjamin1-1/+45
I was inspired to look at this again recently and noticed we could do a bit better. Instead of a tower of selects, rely on all the cases being mutually exclusive and use the ret |= mask & value formulation without loss in clarity. We do need to fixup the invalid case slightly, but since that computation is mostly independent, I'm guessing the CPU and compiler are able to schedule it effectively. Before: Did 251000 base64 decode operations in 2002569us (159.4 MB/sec) After: Did 346000 base64 decode operations in 2005426us (219.5 MB/sec) [+37.7%] Change-Id: I542167202fd4e94c93dd5a2519a97bc388072c89 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49525 Reviewed-by: Adam Langley <agl@google.com>
2021-09-16Ignore SIGPIPE in the bssl tool.David Benjamin1-0/+3
Bug: 435 Change-Id: I0ed94d40d04ebc26c9996dfe2b947a6e2f140a89 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49465 Reviewed-by: Adam Langley <agl@google.com>
2021-08-30Benchmark RSA private key parsing.David Benjamin1-0/+10
We do non-trivial work when parsing RSA private keys (RSA_check_key) and, in some consumers, this is performance-sensitive. Bug: b/192484677 Change-Id: Ic27f5f11d8bd030de77dd500a826fb2dd7c5b75d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49105 Reviewed-by: Adam Langley <agl@google.com>
2021-08-02generate_ech.cc: include needed headersAdam Langley1-0/+1
Change-Id: I04c8bb68801aeb0938e5b038b98811ca4ffe50f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48685 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-07-20Add 'generate-ech' command to bssl toolDan McArdle6-18/+157
The tool generates three files: an ECHConfig, its corresponding private key, and the ECHConfig wrapped in an ECHConfigList. For example, the following invocation generates the files: bssl generate-ech \ -out-ech-config-list ech_config_list.data \ -out-ech-config ech_config.data \ -out-private-key ech.key \ -public-name foo.example \ -config-id 0 Now, we can pass the ECHConfig and private key into the 'server' and 'client' commands: bssl server -accept 4430 \ -ech-config ech_config.data \ -ech-key ech.key bssl client -connect localhost:4430 \ -ech-config-list ech_config_list.data Bug: 275 Change-Id: Id4342855483fb01aa956f9aff356105c4a8ca4f6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48466 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-07-20Check strtoul return for overflow error in GetUnsigned()Dan McArdle1-3/+7
Currently, GetUnsigned() calls strtoul and checks whether the resulting unsigned long int is greater than UINT_MAX. This implicitly assumes that UINT_MAX < ULONG_MAX. Problematically, `unsigned long int` and `unsigned` have the same size on Windows [0] and on 32-bit architectures. For correctness, we now check whether strtoul failed because it would overflow the unsigned long int before checking whether the value fits in an unsigned type. [0]: https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges?view=msvc-160 Change-Id: I49702febf4543bfb7991592717443e0b2adb954f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48545 Commit-Queue: Dan McArdle <dmcardle@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-07-15hrss: use less stack space.Adam Langley1-18/+17
The stack consumption of the HRSS functions is causing issues in stack-constrained environments. Therefore allocate many variables on the heap. This means that several HRSS_ functions now allocate, and thus can fail, where they couldn't before. Callers that ignore the return value and don't have crash-on-failure mallocs will still be safe, although things will fail to decrypt later on. Somehow, this actually makes key generation _faster_ on my machine. (I don't know. Better alignment? Fewer L1 collisions?) The other operations are slightly slower, as expected. Before: Did 17390 HRSS generate operations in 3054088us (5694.0 ops/sec) Did 225000 HRSS encap operations in 3000512us (74987.2 ops/sec) Did 87000 HRSS decap operations in 3014525us (28860.3 ops/sec) After: Did 21300 HRSS generate operations in 3026637us (7037.5 ops/sec) Did 221000 HRSS encap operations in 3008911us (73448.5 ops/sec) Did 84000 HRSS decap operations in 3007622us (27929.0 ops/sec) Change-Id: I2312df8909af7d8d250c7c483c65038123f21ad9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48345 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2021-07-12Add a pointer alignment helper function.David Benjamin1-10/+8
Also use a slightly more conservative pattern. Instead of aligning the pointer as a uintptr_t and casting back, compute the offset and advance in pointer space. C guarantees that casting from pointer to uintptr_t and back gives the same pointer, but general integer-to-pointer conversions are generally implementation-defined. GCC does define it in the useful way, but this makes fewer dependencies. Change-Id: I70c7af735e892fe7a8333b78b39d7b1f3f1cdbef Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48405 Reviewed-by: Adam Langley <alangley@gmail.com>
2021-06-14Add an option to permute ClientHello extension order.David Benjamin1-0/+9
Although not permitted by the TLS specification, systems sometimes ossify TLS extension order, or byte offsets of various fields. To keep the ecosystem healthy, add an API to reorder ClientHello extensions. Since ECH, HelloRetryRequest, and HelloVerifyRequest are sensitive to extension order, I've implemented this by per-connection permutation of the indices in the kExtensions structure. This ensures that all ClientHellos within a connection are consistently ordered. As follow-up work, permuting the other messages would also be nice, though any server messages would need to be incorporated in handshake hints. Change-Id: I18ce39b4df5ee376c654943f07ec26a50e0923a9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48045 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-06-11Add most of an ECH client implementation.David Benjamin1-0/+25
Based on an initial implementation by Dan McArdle at https://boringssl-review.googlesource.com/c/boringssl/+/46784 This CL contains most of a client implementation for draft-ietf-tls-esni-10. The pieces missing so far, which will be done in follow-up CLs are: 1. While the ClientHelloInner is padded, the server Certificate message is not. I'll add that once we resolve the spec discussions on how to do that. (We were originally going to use TLS record-level padding, but that doesn't work well with QUIC.) 2. The client should check the public name is a valid DNS name before copying it into ClientHelloOuter.server_name. 3. The ClientHelloOuter handshake flow is not yet implemented. This CL can detect when the server selects ClientHelloOuter, but for now the handshake immediately fails. A follow-up CL will remove that logic and instead add the APIs and extra checks needed. Otherwise, this should be complete, including padding and compression. The main interesting point design-wise is that we run through ClientHello construction multiple times. We need to construct ClientHelloInner and ClientHelloOuter. Then each of those has slight variants: EncodedClientHelloInner is the compressed form, and ClientHelloOuterAAD just has the ECH extension erased to avoid a circular dependency. I've computed ClientHelloInner and EncodedClientHelloInner concurrently because the compression scheme requires shifting the extensions around to be contiguous. However, I've computed ClientHelloOuterAAD and ClientHelloOuter by running through the logic twice. This probably can be done better, but the next draft revises the construction anyway, so I'm thinking I'll rework it then. (In the next draft, we use a placeholder payload of the same length, so we can construct the ClientHello once and fill in the payload.) Additionally, now that we have a client available in ssl_test, this adds a threading test to confirm that SSL_CTX_set1_ech_keys is properly synchronized. (Confirmed that, if I drop the lock in SSL_CTX_set1_ech_keys, TSan notices.) Change-Id: Icaff68b595035bdcc73c468ff638e67c84239ef4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48004 Reviewed-by: Adam Langley <agl@google.com>
2021-06-11Make ECH server APIs take EVP_HPKE_KEY.David Benjamin1-21/+23
Previously we would extract the KEM ID from the ECHConfig and then parse the private key using the corresponding KEM type. This CL makes it take a pre-pared EVP_HPKE_KEY and checks it matches. This does require the caller pass the key type through externally, which is probably prudent? (On the other hand we are still inferring config from the rest of the ECHConfig... maybe we can add an API to extract the EVP_HPKE_KEM from a serialized ECHConfig if it becomes a problem. I could see runner or tool wanting that out of convenience.) The immediate motivation is to add APIs to programmatically construct ECHConfigs. I'm thinking we can pass a const EVP_HPKE_KEY * to specify the key, at which point it's weird for SSL_ECH_KEYS_add to look different. Bug: 275 Change-Id: I2d424323885103d3fe0a99a9012c160baa8653bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48002 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-06-10Rename SSL_ECH_SERVER_CONFIG_LIST to SSL_ECH_KEYS.David Benjamin1-8/+7
The old name was really long and a bit tedious to type out. Bug: 275 Change-Id: Ie24ef811f9288e619148a2bed36ca34b67af0a3a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48001 Reviewed-by: Adam Langley <agl@google.com>
2021-06-03Add SSL_ech_accepted API and ech_is_required alerts.David Benjamin1-0/+3
The first thing any deployment will want to monitor is whether ECH was actually used. Also it's useful if the command-line tool can output this. (The alert is how the client signals it discarded the connection due to ECH reject.) This also disables ECH with the handoff mechanism for now. (The immediate cause being that ech_accept isn't serialized.) We'll probably need to make some decisions around the ordering here, since ECH affects where the true ClientHello is available. Bug: 275 Change-Id: Ie4559733290e653a514fcd94431090bf86bc3172 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47911 Reviewed-by: Adam Langley <agl@google.com>
2021-05-24Don't try to write empty early data in the tool.David Benjamin1-9/+11
We'll return 0 and get confused. (Negotiating early data and not using it is plausible if, say, the client preconnects but gets a ServerHello before any request binds the socket.) Change-Id: I94d458e18c58223f73c9340cac06e5ec5f8c84a0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47684 Reviewed-by: Adam Langley <agl@google.com>
2021-04-08Add ECH server (draft-ietf-tls-esni-09).Daniel McArdle1-0/+51
This CL adds an initial implementation of the ECH server, with pieces of the client in BoGo as necessary for testing. In particular, the server supports ClientHelloInner compression with ech_outer_extensions. When ECH decryption fails, it can send retry_configs back to the client. This server passes the "ech-accept" and "ech-reject" test cases in tls-interop-runner[0] when tested against both the cloudflare-go and nss clients. For reproducibility, I started with the main branch at commit 707604c262d8bcf3e944ed1d5a675077304732ce and updated the endpoint's script to pass the server's ECHConfig and private key to the boringssl tool. Follow-up CLs will update HPKE to the latest draft and catch us up to draft-10. [0]: https://github.com/xvzcf/tls-interop-runner Bug: 275 Change-Id: I49be35af46d1fd5dd9c62252f07d0bae179381ab Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45285 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2021-01-27Benchmark BORINGSSL_self_test in FIPS mode.David Benjamin1-0/+24
Probably worth benchmarking this, given it slows down every process startup. Change-Id: I603c79a445203f87e26fa23d9afc4450688f2929 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45245 Reviewed-by: Adam Langley <agl@google.com>
generated by cgit v1.1 at 2024-06-29 00:10:50 +0000