aboutsummaryrefslogtreecommitdiff
path: root/tool
AgeCommit message (Collapse)AuthorFilesLines
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>
2021-01-26Add basic BLAKE2b-256 support.Adam Langley1-0/+1
Our use-case for this does not require optimisation at the current time, so a clean C implementation is fine. Change-Id: I8f29572c33e8dbcc37961c099c71c14aafc8d0a3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45164 Reviewed-by: David Benjamin <davidben@google.com>
2021-01-08Use gai_strerrorA on Windows.David Benjamin1-1/+6
gai_strerror is one of the Windows functions which behaves differently whether UNICODE is defined. See https://docs.microsoft.com/en-us/windows/win32/intl/conventions-for-function-prototypes Call gai_strerrorA so that we behave consistently in both modes. This fixes the build failure in https://chromium-review.googlesource.com/c/chromium/src/+/2613519. It also fixes a type error in the connect BIO (built but not used in Chromium), which wasn't noticed because ERR_add_error_data is a variadic function and untyped. (The type error won't go out of bounds because we're interpreting a NUL-terminated WCHAR* as a NUL-terminated char*. The string will be misinterpreted, but it still will be terminated either at the NUL WCHAR or, more likely, the upper zero byte of the first Latin-1 character in the string.) The ERR_add_error_data call raises the question of which of our char* strings are UTF-8 and which are the POSIX locale / Windows code page (when those are not also UTF-8). This CL doesn't address this and only fixes the character width error. Realistically, calling code tosses char* to printf so often that non-UTF-8 locales are probably a lost cause. (Although right now we do not transform any OS error strings, so tossing them to printf works fine. The outputs of functions like ASN1_STRING_to_UTF8, not so much.) Change-Id: Ie789730658829bde90022605ade2c86b8a65c3de Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44964 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2020-10-08Update TrustTokenV2 to use VOPRFs and assemble RR.Steven Valdez1-16/+27
Change-Id: I2f1f6b187bf42ebfdb61def73726d95740a9d55c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42965 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-07-09Link to ws2_32 more consistently.David Benjamin1-0/+4
This fixes a couple issues: - Which libraries to use should be based on WIN32, not MSVC. - Windows libraries can be specified by #pragma comment lines in the source or by build dependencies. We specified #pragma lines in source, but also have build dependencies in crypto_test, etc. The latter was missing bssl. The comment line should be sufficient, but being explicit is useful, so fill in the missing one. This should help building with MINGW, which is missing support for the usual Windows pragma. Change-Id: Ide9328c7dd306738ebbb0792e47da96948fe12f4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42105 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2020-07-07Remove TRUST_TOKEN_experiment_v0.Steven Valdez1-30/+0
Update-Note: This gets rid of TRUST_TOKEN_experiment_v0. Existing callers should be updated to call TRUST_TOKEN_experiment_v1. Change-Id: I8ec9b808cbd35546425690d1548db671ff033e14 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41524 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com>
2020-06-17Fixes warning when redefining PATH_MAX when building with MINGW.Jesko Jochum1-0/+2
Fixes warning thrown when compiling digest.cc with MinGW64, by only defining PATH_MAX, if it has not yet been defined. Else building with MinGW64, throws the following warning: <PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:39: warning: "PATH_MAX" redefined 39 | #define PATH_MAX MAX_PATH | In file included from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:194, from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/syslimits.h:7, from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:34, from C:/msys64/mingw64/x86_64-w64-mingw32/include/pthread.h:67, from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr-default.h:35, from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr.h:148, from C:/msys64/mingw64/include/c++/9.3.0/ext/atomicity.h:35, from C:/msys64/mingw64/include/c++/9.3.0/memory:73, from <PATH_TO_SOURCE_FOLDER>/boringssl/src/include/openssl/base.h:473, from <PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:15: C:/msys64/mingw64/x86_64-w64-mingw32/include/limits.h:20: note: this is the location of the previous definition 20 | #define PATH_MAX 260 | Change-Id: I29eb33ee8fad9e4e80d9348a0d5e4057dfac620c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41705 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2020-06-16Abstract fd operations better in tool.David Benjamin6-106/+232
Windows and POSIX implement very similar fd operations, but differ slightly: - ssize_t in POSIX is usually int on Windows. - POSIX needs EINTR retry loops. - Windows wants _open rather than open, etc. - POSIX fds and sockets are the same thing, while Windows sockets are HANDLEs and leaves fd as a C runtime construct. Rather than ad-hoc macros and redefinitions of ssize_t (which reportedly upset MINGW), add some actual abstractions. While I'm here, add a scoped file descriptor type. That still leaves recv/send which are only used in one file, so defined a socket_result_t for them. Change-Id: I17fca2a50c77191f573852bfd27553996e3e9c3f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41725 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2020-05-04Introduce TRUST_TOKENS_experiment_v1.David Benjamin1-0/+4
This starts a new branch of the protocol using P-384 and draft-07 of hash-to-curve. Mark it unstable for now as we aim to add batching and other fixes. Did 154 TrustToken-Exp0-Batch1 generate_key operations in 1033312us (149.0 ops/sec) Did 748 TrustToken-Exp0-Batch1 begin_issuance operations in 1078707us (693.4 ops/sec) Did 48 TrustToken-Exp0-Batch1 issue operations in 1030056us (46.6 ops/sec) Did 44 TrustToken-Exp0-Batch1 finish_issuance operations in 1092816us (40.3 ops/sec) Did 6040750 TrustToken-Exp0-Batch1 begin_redemption operations in 1000009us (6040695.6 ops/sec) Did 154 TrustToken-Exp0-Batch1 redeem operations in 1023722us (150.4 ops/sec) Did 18000 TrustToken-Exp0-Batch1 finish_redemption operations in 1021087us (17628.3 ops/sec) Did 154 TrustToken-Exp0-Batch10 generate_key operations in 1032878us (149.1 ops/sec) Did 72 TrustToken-Exp0-Batch10 begin_issuance operations in 1050908us (68.5 ops/sec) Did 4 TrustToken-Exp0-Batch10 issue operations in 1051989us (3.8 ops/sec) Did 4 TrustToken-Exp0-Batch10 finish_issuance operations in 1214996us (3.3 ops/sec) Did 5987000 TrustToken-Exp0-Batch10 begin_redemption operations in 1000068us (5986592.9 ops/sec) Did 154 TrustToken-Exp0-Batch10 redeem operations in 1037898us (148.4 ops/sec) Did 18000 TrustToken-Exp0-Batch10 finish_redemption operations in 1024788us (17564.6 ops/sec) Did 396 TrustToken-Exp1-Batch1 generate_key operations in 1060955us (373.2 ops/sec) Did 1925 TrustToken-Exp1-Batch1 begin_issuance operations in 1093039us (1761.1 ops/sec) Did 121 TrustToken-Exp1-Batch1 issue operations in 1022292us (118.4 ops/sec) Did 110 TrustToken-Exp1-Batch1 finish_issuance operations in 1076011us (102.2 ops/sec) Did 6322000 TrustToken-Exp1-Batch1 begin_redemption operations in 1000144us (6321089.8 ops/sec) Did 407 TrustToken-Exp1-Batch1 redeem operations in 1087774us (374.2 ops/sec) Did 18000 TrustToken-Exp1-Batch1 finish_redemption operations in 1031736us (17446.3 ops/sec) Did 407 TrustToken-Exp1-Batch10 generate_key operations in 1090415us (373.3 ops/sec) Did 187 TrustToken-Exp1-Batch10 begin_issuance operations in 1065754us (175.5 ops/sec) Did 11 TrustToken-Exp1-Batch10 issue operations in 1005738us (10.9 ops/sec) Did 10 TrustToken-Exp1-Batch10 finish_issuance operations in 1066494us (9.4 ops/sec) Did 6302000 TrustToken-Exp1-Batch10 begin_redemption operations in 1000029us (6301817.2 ops/sec) Did 407 TrustToken-Exp1-Batch10 redeem operations in 1087692us (374.2 ops/sec) Did 18000 TrustToken-Exp1-Batch10 finish_redemption operations in 1014611us (17740.8 ops/sec) Change-Id: I7ea9a8ab8ad48acfbf50026e251cc6e1d5b8ba7f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41069 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: Steven Valdez <svaldez@google.com>
2020-05-01Introduce a TRUST_TOKEN_METHOD hook to select TRUST_TOKEN variations.David Benjamin1-12/+15
For now, it does nothing. This will make it easier to transition between versions of the experiment while the protocol evolves. Update-Note: Pass TRUST_TOKEN_experiment_v0() into any existing code that now needs a TRUST_TOKEN_METHOD. Change-Id: I434e18c794ab30545e367eb902e434e6311b7497 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41066 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com>
2020-05-01Fix the types used in token counts.David Benjamin1-4/+2
The number of tokens is inconsistent throughout the API. max_batchsize is a uint16_t. max_issuance is a size_t. out_tokens_issued is a uint8_t*. The serialization only supports up to uint16_t. Standardize on size_t. The natural size for a count of elements is size_t. Protocol limitations can be handled within the implementation. Additionally, it is best not to use small types for counters in public APIs in C/C++ because the language has implicit truncating conversions. (Whereas code points or other enum-like values are fine because the caller won't managed to get a 32-bit cipher suite.) Update-Note: Fix callers of TRUST_TOKEN_ISSUER_issue to use size_t instead of uint8_t. The max_batchsize changes should go through without changes to the caller. Change-Id: I9be5dd8f61abdbe5a1dbe70b8dc72d06114b1022 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41044 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com>
2020-04-30Switch the P-384 hash-to-curve to draft-07.David Benjamin1-4/+4
Leave the P-521 one alone as it's part of the current trust token experiment. But suffix all the functions by their draft until everything stabilizes. Also remove the ref_for_testing function since we can cite the fixed test vectors from the upstream PR. Change-Id: Ied89d26848c8ec1f6e8414a2385d9f3e491d7fb2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41067 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Steven Valdez <svaldez@google.com>
2020-04-29Add hash-to-curve code for P384.Steven Valdez1-20/+48
Change-Id: I34c3609641c23aed14f2324c6887250369ae8b5f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40944 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-04-23Benchmark ECDH slightly more accurately.David Benjamin1-6/+3
We really need a better ECDH API in the first place, but ECDH would not extract the y-coordinate which saves a couple multiplications. (This is entirely unnoticeable between everything else going on in ECDH.) Change-Id: I663554577b0cfc373067f9db4d2116a3dfbf1478 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40866 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Steven Valdez <svaldez@google.com>
2020-04-22Add bssl speed support for hashtocurve and trusttoken.Steven Valdez1-1/+282
Change-Id: I74bee1855c593131bf1451553de6a56b4e0e8a54 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40804 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-04-15Add SHA-512-256.Adam Langley3-0/+6
(Not wired up into all the signature verifiers because we don't need or recommend that.) Change-Id: Ia212a1f0e1c389a31d303e00a6fafb0ec3db7c71 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40704 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2020-02-06Remove SSL_CTX_set_ed25519_enabled.David Benjamin1-7/+0
We never ended up using this, and callers can still configure SSL_CTX_set_verify_algorithm_prefs to enable Ed25519 on the receiving side. (On the sending side, this API was never needed because it's a function of what certificate you configure.) This was just a way to tweak the default without requiring callers restate the order. Change-Id: I38d7f91d85430f37fc7e278d77466e78a0cbfa0d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39848 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2020-02-06Add a -sigalgs option to bssl client.David Benjamin1-0/+11
Change-Id: I6247e02c6a9a9cc6ff5005eafe96f89f864cb12c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39846 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2020-01-10Add bssl client option to load a hashed directory of cacerts.Pete Bentley1-1/+17
Useful for debugging TLS issues on Android. Change-Id: Ibdf9233b30e297dbab6be86a4f6b1a9eab593dbf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39464 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
2019-11-07Fix build warning if _SCL_SECURE_NO_WARNINGS is defined globallyDavid Benjamin1-0/+2
Thanks to shohei.yoshida@dena.jp for reporting the issue and providing a patch. Bug: 302 Change-Id: I1200a917ef4b791822712feafece19cb21988d55 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38684 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-10-18Drop CECPQ2b code.fips-android-20191020Adam Langley1-61/+0
The experiment which motivated CECPQ2b has concluded (although the results haven't been published yet) and the SIKE code is causing some issues for gRPC in gprc/grpc#20100. Also, this is code size that takes up space in Android etc. Change-Id: I43b0b8c420f236c0fe9b40bf2517d2fde98495d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38384 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-10-02tool: add -json flag to |speed|Zola Bridges1-25/+86
Add a flag to speed.cc to generate machine-readable benchmark results. Change-Id: I24a4324c5195b15494dc6d9471aa91c27b9f881d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37865 Reviewed-by: Adam Langley <alangley@gmail.com> Reviewed-by: Zola Bridges <zbrid@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-09-13Add benchmarks for AES block operations.David Benjamin1-0/+72
While not the most important operation, it is used in QUIC packet number encryption. Change-Id: I13a04e7a24d90c30804bb6020547d6060e1e7e87 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37424 Reviewed-by: Adam Langley <agl@google.com>
2019-08-21Add a function to convert SSL_ERROR_* values to strings.David Benjamin1-1/+2
Unexpected SSL_ERROR_* values usually mean the caller didn't handle an error case for some opt-in feature, but it still would be handy to stringify them when logging. Change-Id: If1c44a180b5c124a51ba61410ba02bd637f3429a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37188 Reviewed-by: Adam Langley <agl@google.com>
2019-07-16Implements SIKE/p434Kris Kwiatkowski1-10/+10
* CECPQ2b will use SIKE/p434 instead of SIKE/p503 * KEM uses SHA256 instead of HMAC-256 * implements new starting curve: y^2=x^3 + 6x^2 + x * adds optimized implementation for aarch64 * adds optimized implementation for AMD64 which do not support MULX/ADOX/ADCX * syncs the SIKE test code with the NIST Round 2 specification. * removes references to field size from variables names, tests and defines. Change-Id: I5359c6c62ad342354c6d337f7ee525158586ec93 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36704 Reviewed-by: Adam Langley <agl@google.com>
2019-05-16Add support for SIKE/p503 post-quantum KEMKris Kwiatkowski1-0/+61
Based on Microsoft's implementation available on github: Source: https://github.com/Microsoft/PQCrypto-SIDH Commit: 77044b76181eb61c744ac8eb7ddc7a8fe72f6919 Following changes has been applied * In intel assembly, use MOV instead of MOVQ: Intel instruction reference in the Intel Software Developer's Manual volume 2A, the MOVQ has 4 forms. None of them mentions moving literal to GPR, hence "movq $rax, 0x0" is wrong. Instead, on 64bit system, MOV can be used. * Some variables were wrongly zero-initialized (as per C99 spec). * Rewrite x86_64 assembly to AT&T format. * Move assembly for x86_64 and aarch64 to perlasm. * Changes to aarch64 assembly, to avoid using x18 platform register. Assembly also correctly constructs linked list of stack-frames as described in AAPCS64, 5.2.3. * Move constant values to .RODATA segment, as keeping them in .TEXT segment is not compatible with XOM. * Fixes issue in arm64 code related to the fact that compiler doesn't reserve enough space for the linker to relocate address of a global variable when used by 'ldr' instructions. Solution is to use 'adrp' followed by 'add' instruction. Relocations for 'adrp' and 'add' instructions is generated by prefixing the label with :pg_hi21: and :lo12: respectively. * Enable MULX and ADX. Code from MS doesn't support PIC. MULX can't reference global variable directly. Instead RIP-relative addressing can be used. This improves performance around 10%-13% on SkyLake * Check if CPU supports BMI2 and ADOX instruction at runtime. On AMD64 optimized implementation of montgomery multiplication and reduction have 2 implementations - faster one takes advantage of BMI2 instruction set introduced in Haswell and ADOX introduced in Broadwell. Thanks to OPENSSL_ia32cap_P it can be decided at runtime which implementation to choose. As CPU configuration is static by nature, branch predictor will be correct most of the time and hence this check very often has no cost. * Reuse some utilities from boringssl instead of reimplementing them. This includes things like: * definition of a limb size (use crypto_word_t instead of digit_t) * use functions for checking in constant time if value is 0 and/or less then * #define's used for conditional compilation * Use SSE2 for conditional swap on vector registers. Improves performance a little bit. * Fix f2elm_t definition. Code imported from MSR defines f2elm_t type as a array of arrays. This decays to a pointer to an array (when passing as an argument). In C, one can't assign const pointer to an array with non-const pointer to an array. Seems it violates 6.7.3/8 from C99 (same for C11). This problem occures in GCC 6, only when -pedantic flag is specified and it occures always in GCC 4.9 (debian jessie). * Fix definition of eval_3_isog. Second argument in eval_3_isog mustn't be const. Similar reason as above. * Use HMAC-SHA256 instead of cSHAKE-256 to avoid upstreaming cSHAKE and SHA3 code. * Add speed and unit tests for SIKE. Some speed results: Skylake (64-bit): Did 408 SIKE/P503 generate operations in 1002573us (407.0 ops/sec) Did 275 SIKE/P503 encap operations in 1070570us (256.9 ops/sec) Did 264 SIKE/P503 decap operations in 1098955us (240.2 ops/sec) Skylake (32-bit): Did 9 SIKE/P503 generate operations in 1051620us (8.6 ops/sec) Did 5 SIKE/P503 encap operations in 1038251us (4.8 ops/sec) Did 5 SIKE/P503 decap operations in 1103617us (4.5 ops/sec) Change-Id: I22f0bb1f9edff314a35cd74b48e8c4962568e330 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35204 Reviewed-by: Adam Langley <alangley@gmail.com>
2019-05-14tool: fix speed tests.Adam Langley1-2/+2
16K is a tested chunk size, but a couple of functions didn't have a large enough buffer and so would fail. (Cleanly, but it stopped subsequent executions.) Change-Id: Ic11ba7b9055ab72dbf056a4c79dfc251cb511fb3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36044 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2019-03-20Add 16384 to the default bssl speed sizes.David Benjamin1-2/+2
When servers have a lot of data to send and aren't as latency-sensitive, it makes sense to send large TLS records, so we care about measuring both packet-sized and full-sized payloads. Change-Id: Ib0cf5e0f8660f68a98a04fa86b5989d4a485528b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35344 Reviewed-by: Adam Langley <agl@google.com>
2019-02-25Add an option to configure bssl speed chunk size.David Benjamin1-28/+95
bsaes, in its current incarnation, hits various pathological behaviors at different input sizes. Make it easy to experiment around them. Bug: 256 Change-Id: Ib6c6ca7d06a570dbf7d4d2ea81c1db0d94d3d0c4 Reviewed-on: https://boringssl-review.googlesource.com/c/34876 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2019-01-08Delete the variants/draft code.Steven Valdez2-68/+0
Change-Id: I84abfedc30e4c34e42285f3c366c2f504a3b9cf2 Reviewed-on: https://boringssl-review.googlesource.com/c/34144 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2018-12-19HRSS: omit reconstruction of ciphertext.Adam Langley1-2/+2
In [1], section 5.1, an optimised re-encryption process is given. In the code, this simplifies to not needing to rebuild the ciphertext at all. Thanks to John Schanck for pointing this out. [1] https://eprint.iacr.org/2018/1174.pdf Change-Id: I807bd509e936b7e82a43e8656444431546e9bbdf Reviewed-on: https://boringssl-review.googlesource.com/c/33705 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2018-12-12Add initial HRSS support.Adam Langley1-1/+58
This change includes support for a variant of [HRSS], a post-quantum KEM based on NTRU. It includes changes suggested in [SXY]. This is not yet ready for any deployment: some breaking changes, like removing the confirmation hash, are still planned. (CLA for HRSS's assembly code noted in b/119426559.) [HRSS] https://eprint.iacr.org/2017/667.pdf [SXY] https://eprint.iacr.org/2017/1005.pdf Change-Id: I85d813733b066d5c578484bdd248de3f764194db Reviewed-on: https://boringssl-review.googlesource.com/c/33105 Reviewed-by: David Benjamin <davidben@google.com>
2018-11-21Work around a JDK 11 TLS 1.3 bug.David Benjamin1-0/+8
JDK 11 shipped with a TLS 1.3 implementation enabled by default. Unfortunately, that implementation does not work and fails to send the SNI extension on resumption. See https://bugs.openjdk.java.net/browse/JDK-8211806. This means servers which enable TLS 1.3 will see JDK 11 clients work on the first connection and then fail on all subsequent connections. Add SSL_set_jdk11_workaround which configures a workaround to fingerprint JDK 11 and disable TLS 1.3 with the faulty clients. JDK 11 also implemented the downgrade signal, which means that connections that trigger the workaround also must not send the downgrade signal. Unfortunately, the downgrade signal's security properties are sensitive to the existence of any unmarked TLS 1.2 ServerHello paths. To salvage this, pick a new random downgrade marker for this scenario and modify the client to treat it as an alias of the standard one. Per the link above, JDK 11.0.2 will fix this bug. Hopefully the workaround can be retired sometime after it is released. Change-Id: I0627609a8cadf7cc214073eb7f1e880acdf613ef Reviewed-on: https://boringssl-review.googlesource.com/c/33284 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-09-06Support symbol prefixesJoshua Liebow-Feeser1-0/+2
- In base.h, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols.h - In all .S files, if BORINGSSL_PREFIX is defined, include boringssl_prefix_symbols_asm.h - In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are defined with appropriate values depending on whether BORINGSSL_PREFIX is defined; these macros are used in place of 'namespace bssl {' and '}' - Add util/make_prefix_headers.go, which takes a list of symbols and auto-generates the header files mentioned above - In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS are defined, run util/make_prefix_headers.go to generate header files - In various CMakeLists.txt files, add "global_target" that all targets depend on to give us a place to hook logic that must run before all other targets (in particular, the header file generation logic) - Document this in BUILDING.md, including the fact that it is the caller's responsibility to provide the symbol list and keep it up to date - Note that this scheme has not been tested on Windows, and likely does not work on it; Windows support will need to be added in a future commit Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2 Reviewed-on: https://boringssl-review.googlesource.com/31364 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-28Switch the default TLS 1.3 variant to tls13_rfc.David Benjamin2-0/+8
Update-Note: If not explicitly configured to use tls13_all, callers that enable TLS 1.3 will now only enable the final standard version. Change-Id: Ifcfc65a9d8782c983df6e002925e8f77f45b6e53 Reviewed-on: https://boringssl-review.googlesource.com/31384 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-08-13Implement final TLS 1.3 RFC!!!Steven Valdez2-0/+8
The anti-downgrade signal is being implemented in a follow-up change. Change-Id: I5ea3ff429ed1389a3577026588fef3660d2d0615 Reviewed-on: https://boringssl-review.googlesource.com/30904 Commit-Queue: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>
2018-08-10Align on a single CMake style.David Benjamin1-2/+2
We currently write a mix of "if (FOO)" and "if(FOO)". While the former looks more like a usual language, CMake believes everything, even "if" and "else", is just a really really funny function call (a "command"). We should pick something for consistency. Upstream CMake writes "if(FOO)", so go with that one. Change-Id: I67e0eb650a52670110b417312a362c9f161c8721 Reviewed-on: https://boringssl-review.googlesource.com/30807 Reviewed-by: Adam Langley <agl@google.com>
2018-06-28Remove SSL 3.0 implementation.David Benjamin1-4/+1
Update-Note: SSL_CTX_set_min_proto_version(SSL3_VERSION) now fails. SSL_OP_NO_SSLv3 is now zero. Internal SSL3-specific "AEAD"s are gone. Change-Id: I34edb160be40a5eea3e2e0fdea562c6e2adda229 Reviewed-on: https://boringssl-review.googlesource.com/29444 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2018-06-04Add missing <condition_variable> include.David Benjamin1-0/+1
Change-Id: I07040cabcef191f0ab4a7b0e9bd4d46b37b09169 std::condition_variable has its own header to include. Reviewed-on: https://boringssl-review.googlesource.com/28904 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-21Benchmark TLS AES-CBC ciphers in both directions.David Benjamin1-6/+21
Between CBC being only parallelizable in one direction, bsaes vs vpaes, and the Lucky 13 fix, seal and open look very different here. Benchmark both directions. Change-Id: I9266ab2800adc29dbeee0ca74502addb92409e23 Reviewed-on: https://boringssl-review.googlesource.com/28644 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-10Allow enabling all TLS 1.3 variants by setting |tls13_default|.Steven Valdez2-3/+22
Update-Note: Enabling TLS 1.3 now enables both draft-23 and draft-28 by default, in preparation for cycling all to draft-28. Change-Id: I9405f39081f2e5f7049aaae8a9c85399f21df047 Reviewed-on: https://boringssl-review.googlesource.com/28304 Commit-Queue: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2018-05-10Don't keep trying to read from stdin after EOF.David Benjamin1-0/+3
I added the flag but forgot to do anything with it. Change-Id: I5ad7e1ceed7eca60a3a096c079092ae30b2becbe Reviewed-on: https://boringssl-review.googlesource.com/28305 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-07Fix clang-cl build.David Benjamin1-1/+4
I missed the return value of operator=. Change-Id: Ic8d6ec8feb47e922be56f5fba7aff019c322d6fa Reviewed-on: https://boringssl-review.googlesource.com/28190 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-07Handle blocked writes in bssl client/server.David Benjamin1-42/+60
On Windows, just switching the socket to blocking doesn't work. Instead, switch the stdin half of the waiter to waiting for either socket write or stdin read, depending on whether we're in the middle of trying to write a buffer. Change-Id: I81414898f0491e78e6ab5b28c12148a3909ec1e0 Reviewed-on: https://boringssl-review.googlesource.com/28167 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-05-07Fix bssl handling of buffered read data.David Benjamin1-18/+20
If the peer sends us one record that exceeds buffer, the socket will no longer flag as readable, because data has been consumed, but SSL_read should still be called to drain data. bssl would instead not notice and only surface the data later on. This can (currently) be reproduced by sending "HEAD / HTTP/1.1" to www.google.com. Change-Id: I73cdbe104ba6be56fc033429999e630f0eb852d8 Reviewed-on: https://boringssl-review.googlesource.com/28166 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
generated by cgit v1.1 at 2024-09-18 04:50:56 +0000