summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Inline REDUCE1BIT macro.jsing2025-05-181-15/+6
| | | | | | | | | The REDUCE1BIT macro is now only used in one place, so just inline it. Additionally we do not need separate 32 bit and 64 bit versions - just use the 64 bit version and let the compiler deal with it (we effectively get the same code on i386). ok beck@ joshua@
* bio_mem: avoid pointer arithmetic on NULLtb2025-05-181-2/+4
| | | | | | Prompted by a diff by Kenjiro Nakayama ok jsing
* rc2: two files escaped the lure of the attic, set these poor souls freetb2025-05-182-241/+0
|
* Remove TABLE_BITS from gcm128.jsing2025-05-172-248/+3
| | | | | | | | | TABLE_BITS is always currently defined as 4 - 8 is considered to be insecure due to timing leaks and 1 is considerably slower. Remove code that is not regularly tested, does not serve a lot of purpose and is making clean up harder than it needs to be. ok tb@
* Replace GCM_MUL/GHASH defines with static inline functions.jsing2025-05-161-121/+99
| | | | | | | | | Rather than having defines for GCM_MUL/GHASH (along with the wonder that is GCM_FUNCREF_4BIT) then conditioning on their availability, provide and call gcm_mul()/gcm_ghash() unconditionally. This simplifies all of the call sites. ok tb@
* Increase default PKCS12_SALT_LEN from 8 to 16 bytestb2025-05-101-2/+2
| | | | | | | | | | | | | | Currently PKCS12_setup_mac() function uses salt length of 8 bytes / 64 bits when no salt length is specified. Increase this fallback default to 16 bytes / 128 bits, as recommended by NIST SP 800-132. Note this is for interoperability purposes. Some FIPS implementations enforce minimum salt length of 16 bytes. Examples of such FIPS implemenations are Bouncycastle FIPS Java API and Chainguard FIPS Provider for OpenSSL. Also future v3.6 release of OpenSSL will also increase the default salt length to 16 bytes. From Dimitri John Ledkov, thanks
* asn_moid: move inclusion of err_local.h to the proper placetb2025-05-101-2/+2
|
* Sort FOOerror() in ASCII ordertb2025-05-101-18/+18
|
* Simplify the remaining FOOerror()tb2025-05-101-26/+28
| | | | | | | | Redirect through an additional macro that adds the repeated function, file and line macros. Reduces the eyesore and makes the whole thing much more redable. similar to a suggestion by jsing a while back
* Remove unused internal FOOerror()tb2025-05-101-11/+1
| | | | pointed out by djm a while back
* Remove error macros except PEMerr(), RSAerr() and SSLerr()tb2025-05-101-37/+4
| | | | | | | These three are still used in about half a dozen ports. All the others are unused. ok jsing
* Move the internal FOOerror() to err_local.htb2025-05-102-40/+38
| | | | | | | These are now only used in libcrypto. They should never have been in a public header in the first place. ok jsing
* Use err_local.h rather than err.h in most placestb2025-05-10222-456/+454
| | | | ok jsing
* Garbage collect docs of BIO_dump{,_indent}_{cb,fp}()tb2025-05-091-35/+3
| | | | | The _cb() variants were only documented as intentionally undocumented. Be that as it may, they left the building more than a year ago.
* bss_log.c: don't rely on err.h pulling in bio.htb2025-05-091-2/+2
| | | | ok jsing
* Fix up two markup mistakes with .Fn and .Xrtb2025-05-041-4/+4
|
* Remove the X9.62 prime239v{1,2,3} curvestb2025-05-041-179/+1
| | | | | | | | | | | | | While RFC 3279 allows these curves for use in X.509 certificates (*), no one actually does this. Certs using these curves cannot be used for TLS and the curves aren't accepted by FIPS either. codesearch shows no actual uses of these curves, only their OIDs are listed. At this point these have become useless historical baggage. ok jsing (*) Of the 27 curves listed in RFC 3279 the only one that seems to have seen actual use in certificates is P-256.
* Move P-256 where it belongstb2025-05-041-67/+67
| | | | ok jsing
* Fix typo in curve comment: P224r2 -> P224t1tb2025-05-031-2/+2
|
* CTASSERT that internal pub/priv keys match the sizes exposed in mlkem.htb2025-05-032-2/+10
| | | | | | | This will need reworking (especially deduplicating) anyway, but it doesn't hurt now. From Kenjiro Nakayama
* More space around .Dl + a typo on toptb2025-05-012-5/+11
|
* lhash: add missing spaces before assignment operatortb2025-05-011-4/+4
|
* EC_GROUP_check.3: rephrase a sentence to avoid a word repetitiontb2025-04-281-4/+4
|
* EC_GROUP_new_by_curve_name.3: escape a - in code.tb2025-04-281-3/+3
|
* EC_POINT_point2oct: remove in_ prefix in RETURN VALUEStb2025-04-261-5/+5
|
* EC_GROUP_new_curve_GFp: some fixes in the RETURN VALUE sectiontb2025-04-261-9/+12
|
* Fix markup for EC_GROUP_set_point_conversion_formtb2025-04-261-4/+5
|
* Fix up a few dangling referencestb2025-04-254-13/+12
|
* Rework EC documentationtb2025-04-2513-1242/+1998
| | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the giant, poor quality and outdated EC_GROUP_copy.3, EC_GROUP_new.3, and EC_POINT_new.3 manuals with seven new manuals written from scratch. * EC_GROUP_new_by_curve_name() is the entry point for builtin curves, * EC_GROUP_new_curve_GFp() describes lower level API that should not usually be needed apart from a handful of accessors. * EC_GROUP_check() contains two functions that applications should not need because either you know for certain something is an elliptic curve (so these checks are pointless) or you should not use it. * EC_GROUP_get_curve_name() describes some low level ASN.1 footguns and corresponding getters. * EC_POINT_new() contains the simple EC_POINT allocation and freeing API * EC_POINT_get_affine_coordinates() contains the coordinate accessors * EC_POINT_point2oct() is about encoding elliptic curve points While all this is quite far from perfect, the diff is getting too big and it will be easier to improve this in tree. It is definitely more repetitive than I would like it to be. Reviews, tweaks and general feedback are of course welcome. discussed with jsing
* BN_new: zap an anachronistic admonitiontb2025-04-251-4/+2
| | | | | | | | | -This type should be considered opaque and fields should not be modified -or accessed directly. The type has long been opaque and reasonable people will not do things that permit them to access the fields of opaque types directly. Of course, in the vicinity of OpenSSL code and API all sorts of insanity actually exist.
* Restore two #if defined(GHASH) that were incorrectly removed.jsing2025-04-251-5/+5
| | | | | | | Also condition on defined(GHASH_CHUNK) since this is used within these blocks. This makes the conditionals consistent with other usage. Fixes build with TABLE_BITS == 1.
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing2025-04-251-13/+5
| | | | ok tb@
* Use the OPENSSL_SMALL_FOOTPRINT code in gcm_init_4bit().jsing2025-04-251-32/+2
| | | | | | | | A modern compiler will unroll these loops - LLVM produces identical code (at least on arm64). Drop the manually unrolled version and have code that is more readable and maintainable. ok tb@
* Mop up all of the GETU32/BSWAP4/BSWAP8 macros since they're now unused.jsing2025-04-232-44/+2
| | | | ok beck@ tb@
* Rewrite gcm_gmult_1bit() to avoid sizeof(long) hacks.jsing2025-04-231-22/+8
| | | | | | | | | | | We're already using 64 bit variables, so just continue to do so and let the compiler deal with code generation. While here, use unsigned right shifts instead of relying on signed right shifts and implementation-defined behaviour (which the original code did). Feedback from lucas@ ok beck@ tb@
* Fix CRYPTO_gcm128_decrypt() when compiled with TABLE_BITS == 1.jsing2025-04-231-3/+3
| | | | | | | | | This appears to have been broken since 2013 when OpenSSL commit 3b4be0018b5 landed. This added in_t and out_t variables, but continued to use in and out instead. Yet another reason why untested conditional code is a bad thing. ok beck@ tb@
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing2025-04-235-23/+5
| | | | | | | We do not build with OPENSSL_SMALL_FOOTPRINT and it removes more untested code paths. Request by tb@ (and it was already on my TODO list!)
* Mop up OPENSSL_FIPSAPI define.jsing2025-04-221-3/+1
|
* Use OPENSSL_assert() instead of assert().jsing2025-04-221-10/+6
| | | | | | While here, tidy up the assignment of n and test directly. ok tb@
* Remove now unused PUTU32 macros from modes_local.h.jsing2025-04-221-3/+1
| | | | ok tb@
* Use crypto_load_be32toh()/crypto_store_htobe32() instead of GETU32/PUTU32.jsing2025-04-221-4/+6
| | | | ok tb@
* Mop up unused MODES_DEBUG.jsing2025-04-217-49/+7
|
* Fix another #include that was hiding.jsing2025-04-211-2/+2
|
* Tidy includes.jsing2025-04-216-14/+25
|
* Use standard integer types rather than custom typedefs.jsing2025-04-212-25/+21
| | | | | | Replace u32 with uint32_t, remove unused u16 and replace u8 with uint8_t. ok tb@
* Move AES public functions from aes_core.c to aes.c.jsing2025-04-202-56/+47
| | | | | | This is where almost all of the public functions exist. ok beck@ tb@
* Fix indentation and line wrapping.jsing2025-04-181-17/+15
|
* Remove BS-AES and VP-AES from EVP.jsing2025-04-183-137/+9
| | | | | | | | | | | | | | | | | The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ tb@
* Use 'ctx' for sha3_ctx variables, rather than the less readable 'c'.jsing2025-04-182-36/+36
| | | | ok tb@
* Pull casts from void * to uint8_t * up to variables, rather than inline.jsing2025-04-181-9/+11
| | | | ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-21 11:15:36 +0000