summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* assembly regress: use make's MACHINE_ARCH rather than handrolling itHEADmastertb7 days1-4/+3
| | | | discussed with jsing
* Fix tyojsing8 days1-2/+2
|
* Hook assembly regressjsing8 days1-1/+2
|
* Add a regress test that ensures our pure assembly code builds with gccjsing8 days1-0/+36
| | | | | | This requires egcc to be installed, if not we'll just skip the test. Discussed with tb@
* Make SHA aarch64 assembly build with gcc.jsing8 days3-55/+72
| | | | | | | | | | | | | gcc is extremely fussy about register naming and insists on q and s naming for the ARM CE SHA instructions, even though they're referring to the same register (while LLVM just figures it out). Work around this by mapping registers to their required variant at usage and defining a handful of mappings between v registers and alternate names/views. This is still somewhat ugly, but seems to be one of the cleaner options that will allow portable to enable SHA assembly on platforms that use gcc. ok kenjiro@ tb@
* Tidy instruction separators in SHA assembly.jsing9 days7-113/+113
| | | | | Remove unnecessary separators and add a few to macros that call other macros (instead of expecting them to exist).
* unusally -> unusuallytb10 days3-30/+30
|
* bn_ffdh: unifdef HAVE_SCAPY_SPECIALtb10 days1-7/+1
|
* DH_check: teach this DoS vector about RFC 7919 primestb10 days1-1/+6
| | | | ok beck
* bn_ffdh: unifdef HAVE_RFC7919_PRIMEStb10 days1-8/+1
|
* bn_const: add RFC 7919 primestb10 days2-2/+300
| | | | | | | | There is no intention to expose these via public API or to use them in TLS. For now these will only be used for short-circuiting pointless expensive computations in DH_check(). ok beck
* Scapy special for DH_check()tb10 days1-2/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The latest release of Scapy calls DH_check() on all the well-known Diffie-Hellman parameters for RFCs 2409, 3526, and 7919. It does this via pyca/cryptography at startup. Every single time. This is obviously very expensive, due to our 64 MR rounds (which are complete overkill now that we have BPSW). Instead of pondering the ideal number of rounds for BPSW with FFDH, simply skip the check if the parameter matches a well-known prime. These are known to be safe primes, so we can skip those super-expensive and pointless checks without any risk. This is only done for the public dh->p parameter. It could be further optimized, but with the follow-up commit adding the RFC 7919 primes this reduces the startup time to what it was before Scapy 2.7.0: < 1s. Reverting from 64 MR rounds to BN_check_primes rounds, we would still have ~8s startup time without this optimization, which isn't great for an interactive tool. Clearly, it's not entirely our fault, it's also Scapy and cryptography that do something ... suboptimal, but I think we're better off if DH_check() isn't a complete DoS vector. If you're using non-standard parameters with FFDH, you deserve it. We could consider adding a flag for non-well-known p and thus making DH_check() indicate failure for candidate primes larger than, say, 4k. https://github.com/pyca/cryptography/issues/14048 ok beck kenjiro
* bn regress: add test that double checks the RFC 2409 and 3526 primestb10 days2-1/+505
| | | | | Also has code to check the RFC 7919 primes and run DH_check() once that knows about these.
* wycheproof regress: wycheproof-testvectors was renamed to wycheprooftb11 days1-2/+2
| | | | | Installed packages will update and pkg_add wycheproof-testvectors will continue to work.
* policy test: parital -> partialtb11 days1-2/+2
|
* ML-KEM: unstub runMLKEMKeyGenTest()tb11 days1-1/+50
| | | | | This adds coverage for MLKEM_private_key_from_seed(), which was previously only minimal teted from our regress.
* ML-KEM: improve the EncapsTesttb11 days1-4/+46
| | | | | New testvectors want some more detailed handling, which brings these Wycheproof encapsulation tests about on par with our existing tests.
* ML-KEM: add handler stub for the new KeyGenTesttb11 days1-1/+7
|
* ML_KEM: fix broken test: the encapsulated key is eK, not C...tb11 days1-2/+2
|
* ML-KEM: don't treat API failure as test failure for invalid test casestb11 days1-5/+11
| | | | | An update to the test vectors adds tests which verifies that the API correctly rejects some inputs.
* While almost all the libc locks are taken and released in the sameguenther13 days3-1/+85
| | | | | | | | | | libc call, flockfile() and ftrylockfile() can be called when single-threaded and then--while 'holding' the lock--the process can create another thread, resulting in a broken state. Have the f{lock,trylock,unlock}file() APIs *always* do real locking so the exposed state is always consistent. ok dlg@
* Rewrite ec_point_cmp()tb2026-01-181-59/+97
| | | | | | | | This removes some complications due to handling the fast path for affine points and general points at the same time. The result is a bit more code but both paths should be much easier to follow. ok jsing kenjiro
* mlkem: fix mklem_{generate_key,encap}_external_entropy() declarationstb2026-01-181-5/+3
| | | | | | | | | | The prototypes used sized arrays appropriate only for MLKEM768 while the declarations used pointers. For some reason clang doesn't flag this but gcc does. In any case it was wrong. The callers of these functions check that they pass in the correct size. Which is weird but the mlkem directory has an unbelievable amount of mess and bad code. found by/ok jsing
* mlkem: garbage collect the unusd mlkem_{generate_key,encap}()tb2026-01-182-58/+2
| | | | | | | These are flagged by more recent gcc since declarations and definitions don't match (sized array vs pointer). Also an array was checked for NULL. found by/ok jsing
* Provide LIBRESSL_USE_.*_ASSEMBLY defines.jsing2026-01-1717-31/+104
| | | | | | | | | Make life easier for portable by providing LIBRESSL_USE_.*_ASSEMBLY defines, which enable/disable assembly for a specific algorithm. This means that selected platforms can include the assembly files and specify a define, rather than having to try to patch the crypto_arch.h headers. Discussed with tb@
* Replace MD5_ASM with function specific defines.jsing2026-01-175-9/+11
| | | | | Use the same pattern that is now used for most other code - provide HAVE_MD5_BLOCK_DATA_ORDER and use this to selectively enable source code.
* Replace GHASH_ASM with function specific defines.jsing2026-01-1711-22/+41
| | | | | Use the same pattern that is now used for most other code - provide HAVE_* defines for functions and use these to selectively enable source code.
* Mop up unused AES_ASM and RSA_ASM defines.jsing2026-01-177-15/+7
| | | | These have not been used for quite some time.
* Use .section before .rodata to appease gas.jsing2026-01-178-22/+26
| | | | | | gas dislikes bare .rodata - add .section before .rodata to make it happier (LLVM does not care and is happy with either). For consistency, do the same with .text.
* Use local label prefix for loop labels.jsing2026-01-173-9/+9
|
* mlkem_internal.h: formate -> formattb2026-01-161-2/+2
|
* mlkem_internal.h: some very basic copy editingtb2026-01-161-6/+6
|
* mlkem.h: Thie -> This (2x)tb2026-01-161-3/+3
|
* mlkem.c: becuase -> becausetb2026-01-161-2/+2
|
* asn1t.h: whitespace tweakstb2026-01-161-81/+74
| | | | | | Add missing space after commas, shorten a couple comments in structs, reflow weirdly wrapped long comments and improve the random line breaks in typedefs and prototypes.
* asn1t.h: Otherwiser -> Otherwisetb2026-01-161-2/+2
|
* asn1t.h: more macro cleanup, add missing C99 initializers for ADB_ENTRY()tb2026-01-161-69/+99
| | | | ok kenjiro
* stack.c: avoid arithmetic on pointers to voidtb2026-01-141-2/+2
| | | | | | | | | | | | | | | | | In stack.c r1.34 I converted one 'char *' too many to 'void *', thereby relying on a gcc/clang extension which interprets the fictional void type as a type of size 1 (that's what the stack code wants, fortunately). As pointed out in the link below, -Wpointer-arith would have caught this: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html MSVC flags this as follows: D:\a\portable\portable\crypto\stack\stack.c(211,23): error C2036: 'const void *': unknown size [D:\a\portable\portable\build\crypto\crypto_obj.vcxproj]. Pull in workaround from the portable repo which undoes the char * -> void * conversion. ok jsing millert
* x509_utl.c: zap two useless commentstb2026-01-121-5/+1
|
* More asn1t.h cleanuptb2026-01-111-58/+88
| | | | | | | | This converts more macros to C99 initializers. Rename flags and tags arguments by appending val because they collide with the field names. The remainder are whitespace changes. ok kenjiro
* asn1t.h: add C99 initializers for some ASN.1 templatestb2026-01-091-155/+195
| | | | | | | | | | | | | | This is a first pass at tidying up the unsightly mess that is asn1t.h. For better or worse, we have expanded the macros internally, and in base only rpki-client uses the templates. They are generally rarely used. Fortunately. Having C99 initializers helps a lot with debugging templated ASN.1 by combining cc -E with clang-format. They make the macros more readable, look tidier and help with grep. ok kenjiro
* asn1t.h: whitespace nittb2026-01-091-2/+2
|
* Fix ASN1_ADB_END macro, make it compatible with OpenSSLtb2026-01-071-4/+3
| | | | | | | | | | | | | | In asn1t.h r1.18 (commit 9b72422d) I removed the app_items member from ASN1_ADB and failed to fix up the ASN1_ADB_END() macro that populates the ASN1_ADB. This means ASN1_ADB_END() tried to initialize one member too many and would thus cause a compilation failure, so nobody uses this with LibreSSL. Internally, we have expanded all its uses. We could leave it broken or fix it up. Take the opportunity to add an unused adb_cb() argument instead, making the macro invocation compatible with OpenSSL. ok jsing kenjiro
* ASN.1 templates: make internal *_PUBKEY_it statictb2026-01-051-5/+5
|
* ASN.1 templates: make ASN1_EXTERN_FUNCS statictb2026-01-052-7/+7
| | | | These are used directly only as part of the ASN.1 item in the same file.
* unusally -> unusuallytb2026-01-041-10/+10
|
* a_bitstr: remove parentheses in return statementstb2026-01-041-5/+5
| | | | no binary change
* i2c_ASN1_BIT_STRING() vs ASN1_STRING_FLAG_BITS_LEFTtb2026-01-042-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 suitetb2026-01-041-1/+32
| | | | This is another test that fails due to the bug in i2c_ASN1_BIT_STRING().
* asn1basic: switch test to expect correct encodingtb2026-01-042-4/+6
| | | | This test fails, so mark the asn1basic test as an expected failure