summaryrefslogtreecommitdiff
path: root/src/regress (follow)
Commit message (Collapse)AuthorAgeFilesLines
* unusally -> unusuallytb6 days1-10/+10
|
* i2c_ASN1_BIT_STRING() vs ASN1_STRING_FLAG_BITS_LEFTtb6 days1-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A nasty quirk in the bit string handling is that the serialization produced by i2d_ASN1_BIT_STRING() depends on whether the the magic ASN1_STRING_FLAG_BITS_LEFT is set. If ASN1_STRING_FLAG_BITS_LEFT is set, the number of unused bits is carried in a->flags & 0x07 and the remainder of the bit string is in a->data. This is terrible and undocumented but handled correctly. If ASN1_STRING_FLAG_BITS_LEFT is not set, all trailing zero bits are (intended to be) chopped off with all sorts of hilarious side effects. I broke this quite thoroughly when I incorrectly ported an overflow check from BoringSSL in: https://github.com/openbsd/src/commit/f81cc285d2aed8b36615119a306533696f3eb66c The result is that we currently return ret = a->length + 1 for both NULL and non-NULL pp. The calls to asn1_ex_i2c() in asn1_i2d_ex_primitive() thus report consistent lengths back, making it succeed. asn1_i2d_ex_primitive() therefore skips a->length + 1 bytes, while i2c_ASN1_BIT_STRING() only overwrites len + 1 bytes, which are possibly fewer. So a caller passing in an output buffer containing garbage (malloc) will get some of that garbage back in the encoding. Further, i2c_ASN1_BIT_STRING() also advances that pointer by the possibly reduced len + 1, but that fortunately doesn't matter since that's an effect local to asn1_ex_i2c(), the only caller of i2c_ASN1_BIT_STRING(). The last bit is that the current behavior may set bogus unused bits coming from the scanning backward madness. I added such an example in the parent commit. The fix is simple: use len after the truncation effect was established, not the original a->length, turning this commit into what my backport should have been. This fixes the two currently failing regress tests, so remove expected failure marker again. ok jsing kenjiro
* asn1basic: add missing test from BoringSSL's test suitetb6 days1-1/+32
| | | | This is another test that fails due to the bug in i2c_ASN1_BIT_STRING().
* asn1basic: switch test to expect correct encodingtb6 days2-4/+6
| | | | This test fails, so mark the asn1basic test as an expected failure
* asn1basic: add example showing current bogus encodingtb6 days1-1/+38
| | | | | | There is a bug in i2c_ASN1_BIT_STRING() resulting in nonsense encoding of some BIT STRINGs with trailing zeroes if ASN1_STRING_FLAG_BITS_LEFT is not set (a rare corner case). This test currently passes when it shouldn't.
* check_complete: ASN1_LONG_UNDEF is now internaltb8 days1-1/+0
|
* Rename RANK{768,1024} to MLKEM{768,1024}_RANKtb9 days4-22/+22
| | | | | | | | | RANK768 and RANK1024 are awfully short and generic names for public constants. Before we make it worse with similarly named constants for ML-DSA, let's fix this. This follows the naming convention used by the other macros in the mlkem code. ok kenjiro jsing
* constaints -> constraintstb9 days1-2/+2
|
* preprended -> prependedtb2025-12-271-2/+2
|
* "SCREW_THE_PARITY is not ment to be defined."tb2025-12-261-13/+1
| | | | alright. go home.
* astrix -> asterisktb2025-12-251-2/+2
|
* wycheproof: add minimal glue for the decaps validation teststb2025-12-201-1/+8
|
* openssl appstest: remove to-do item for compress/uncompresstb2025-12-201-5/+1
|
* Port most of BoringSSL's TEST(ASN1Test, SetBit)tb2025-12-181-1/+425
| | | | | | | Exercises the batshit crazy truncation behavior of ASN1_BIT_STRING_set_bit() Based on https://boringssl-review.googlesource.com/c/boringssl/+/48225 (still under ISC).
* ec_asn1_test: change a comma to a full stoptb2025-12-071-2/+2
|
* asn1complex: use ASN1_STRING_get0_data() instead of ASN1_STRING_data()tb2025-12-071-4/+4
|
* check_complete: remove the BN_*FMT1 macros as welltb2025-12-051-4/+1
|
* check_complete: adjust for BN_ macro removaltb2025-12-051-5/+2
| | | | pointed out by kenjiro
* bn_word.c: include bn_local.h in preparation for an upcoming changetb2025-12-051-1/+3
|
* Make the openssh test pass after adding mlkem.beck2025-12-041-8/+9
| | | | | | | | | | This has a magic value looking for what happens when we HRR, more or less assuming it might never change. it now has. Commenting it out get us by it, unsure if we should change this or get rid of it. ok tb@
* Hook up X25519MKLEM768 to the TLS 1.3 handshakebeck2025-12-041-27/+333
| | | | | | | | | | | | | | | | | | | | | | | | This does the following: 1) Adds a second key share prediction to the TLS 1.3 handshake. We only add one as we are unlikely to want to send more than one PQ one, and one classical one and are unlikely to waste bytes on a second PQ algorithm (anything that wants something else that we support can HRR to get it) 2) Adds X25519MLKEM768 (4588) to our list of supported groups. We add this to our preferred client and server key shares for TLS 1.3 and we now have a separate list for TLS 1.2 which does not do this, cleaning up the old "full list" from the comments. 3) Updates the golden magic numbers in the regression tests to allow for the above two things changing the handshake, so the regress tests pass. With this you can successfully hybrid PQ with servers and clients that support it. ok tb@ kenjiro@
* Add a MLKEM768_X25519 hybrid key share.beck2025-12-041-5/+5
| | | | | | | | | | | | This implements the currently in use MLKEM768_X25519 hybrid key share as outlined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ This commit does not yet wire this up to anything, that is done in follow on changes. ok tb@ jsing@ kenjiro@
* bn_test: avoid last use of BN_HEX_FMT1 in libressltb2025-11-151-2/+4
|
* bn_test: remove dead codetb2025-11-151-12/+1
| | | | | | We haven't defined SIXTY_FOUR_BITS in a long time, if ever. The last #undef SIXTY_FOUR_BITS were removed when we cleaned up opensslconf.h. Code behind #ifdef SIXTY_FOUR_BITS is therefore dead.
* Let this compile on m88k.miod2025-11-061-1/+3
|
* Avoid the use of _LP64 in libcrypto regress.jsing2025-11-051-2/+2
| | | | | | | What the tests actually care about is the size of a BN_ULONG, hence condition on BN_BYTES instead. Discussed with tb@
* Needs <sys/param.h> for hppa.miod2025-10-311-3/+3
|
* This test takes *days* to complete on older platforms, reduce the loop countmiod2025-10-261-2/+8
| | | | for them.
* Add some regress coverage for SSL_SESSION_dup()tb2025-10-241-2/+22
| | | | ok kenjiro
* The ssl_verify_param.c test can now link dynamically against libcryptotb2025-10-241-3/+1
|
* Use X509_VERIFY_PARAM_get_hostflags() prototype from x509_vfy.htb2025-10-241-3/+2
|
* Give this test a chance to pass on 32-bit platforms.miod2025-10-201-1/+2
|
* const correct X509_VERIFY_PARAM_get_hostflags()tb2025-10-101-2/+2
| | | | | | | This is currently an internal helper only used by a regress test. We'll have to expose in the public API for Python 3.14: https://github.com/libressl/portable/issues/1202
* Revert previous. Let's deal with it when the portable release is out.tb2025-10-071-7/+3
|
* test framework: allow overriding the "/tmp/" directorytb2025-10-071-3/+7
| | | | | Windows is super picky when it comes to paths, so it needs some special massaging. Will let us avoid a patch or hack in portable.
* ec_asn1_test: add an example using BLS12-377tb2025-09-171-1/+80
| | | | | | This exercises the cofactor guessing code with a large cofactor. Thanks to Daniel Bleichenbacher for pointing out this example. This contains a hack to use a bogus OID since this curve has none.
* wycheproof: provide PBKDF2 test harnesstb2025-09-161-2/+58
| | | | | Skip the tests for now since they increase the test's runtime by ~50%. A later commit will gate these tests behind REGRESS_SKIP_SLOW.
* wycheproof: run HMACSM3 tests against libcryptotb2025-09-151-4/+7
|
* wycheproof: run ML-KEM test vectors against libcryptotb2025-09-141-2/+139
|
* wycheproof: zap stray empty linetb2025-09-091-2/+1
|
* wycheproof: rework test selectiontb2025-09-081-69/+82
| | | | | | | | | | Since this has grown organically, the test selection has become a weird mix of globs, regexes and test variants and it is hard to reason about what is run and why. Instead, load all the json files from testvectors_v1/ and look at algorithm (almost always available) and test schema to figure out if we support it in libcrypto and the test harness. This separates the logic of the test runner better from the test selection. Also make it a fatal error if we don't explicitly skip an unknown algorithm.
* wycheproof: skip tests using curve448/edwards448tb2025-09-081-7/+12
|
* wycheproof: skip tests using SHAKE-128 and SHAKE-256tb2025-09-081-1/+17
|
* wycheproof: rename skipSmallCurve() into skipCurve()tb2025-09-081-4/+6
| | | | | This prepares an upcoming change by not only skipping small curves but also binary curves that have test vectors.
* wycheproof: determine the test variant from the JSON schematb2025-09-081-30/+41
|
* wycheproof: retire the ECDSA webcrypto teststb2025-09-071-71/+2
| | | | | | | The webcrypto test files for P-256, P-384, and P-521 are identical to the P1363 test files for these curves with the hashes SHA-256, SHA-384, and SHA-512, respectively. The only real differences in the test paths is the Go glue code to translate to libcrypto, so they're pointless.
* wycheproof: go fmttb2025-09-061-4/+4
|
* wycheproof: use a cleaner way of dealing with P1363 signature lengthtb2025-09-061-4/+12
|
* wycheproof: check for the v1 directory since v0 will go awaytb2025-09-051-2/+2
|
* wycheproof: port the MI primes check to v1tb2025-09-052-3/+24
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-01-10 05:03:40 +0000