| Commit message (Collapse) | Author | Files | Lines |
|
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@
|
|
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@
|
|
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!)
|
|
|
|
While here, tidy up the assignment of n and test directly.
ok tb@
|
|
ok tb@
|
|
ok tb@
|
|
|
|
|
|
|
|
Replace u32 with uint32_t, remove unused u16 and replace u8 with uint8_t.
ok tb@
|
|
This is where almost all of the public functions exist.
ok beck@ tb@
|
|
Feedback OK tb
|
|
|
|
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@
|
|
|
|
ok jsing
|
|
ok tb@
|
|
|
|
ok tb@
|
|
ok tb@
|
|
ok tb@
|
|
The mix of SHA256 and SHA-256 is jarring, so use FIPS's spelling.
Leave HMAC-SHA256 as it is and fix a nearby RIPEMD-160.
|
|
Now that libc is fixed, we can do this also for md5, rmd160 and sha1.
|
|
|
|
Prompted by a pending diff by claudio
|
|
ok jmc jsing
|
|
The nineties called and wanted their garbage back.
ok jsing
|
|
gcc 14 needs a hint that ld != NULL beyond the use of ld->data in the
previous line. I guess aggressive inlining is becoming too aggressive.
What a pile of junk.
|
|
Some OS declare arc4random() with __attribute__((warn_unused_result))
causing this test to whine. So explicitly ignore the return value.
Reported by scheiba in libressl/portable
Fixes #1151
|
|
|
|
|
|
|
|
|
|
The current documentation was clearly incorrect since a return of -1 from
the methods is explicitly intercepted and translated to 0. schwarze and I
both audited the tree and concluded that only 0 and 1 is possible.
OpenSSL 3 broke this API contract and now has explicit return -1 in the
convoluted 200-line maze this simple function has become with recent
provider improvements. So add a small sentence hinting at that. Nobody
will be surprised to read that with OpenSSL's characteristic penchant
for needless inconsistency the return value checks in their tree are all
over the place and sometimes incorrect.
ok schwarze (with two tweaks)
|
|
EC_POINT_mul() has a complex multi-use interface - there are effectively
three different ways it will behave, depending on which arguments are NULL.
In the case where we compute g_scalar * generator + p_scalar * point, the
mul_double_nonct() function pointer is called, however only g_scalar,
p_scalar and point are passed - it is expected that the lower level
implementation (in this case ec_wnaf_mul()) will use the generator from
the group.
Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that
they take scalar1, point1, scalar2 and point2. This removes all knowledge
of g_scalar and the generator from the multiplication code, keeping it
limited to EC_POINT_mul(). While here also consistently pass scalar then
point, rather than a mix of scalar/point and point/scalar.
ok tb@
|
|
When a non-NULL generator scalar is passed to EC_POINT_mul(), the group's
generator will be used in multiplication. Add a check that ensures that the
group generator is non-NULL, in order to avoid needing to handle this
elsewhere (currently in the lower level point multiplication code).
ok tb@
|
|
This is nearly identical to a leak fixed by miod 10 years ago in
x509_name_canon() but was missed in r1.30. This entire file needs
a metric ton of bleach, but my head currently spins too much for
tackling this, so go with the cheap one-liner.
From Niels Dossche
|
|
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
ok jsing
|
|
|
|
The gibberish that was there before the rewrite didn't actually skip names
whose SN representation was different start with /O= or /OU= (with one or
two capital letters between '/' and '='), it simply failed to separate
them, resulting in nonsense such as
CN=Microsec e-Szigno Root CA 2009/emailAddress=info@e-szigno.hu
So ditch the code doing that, simplifying this now internal function
quite a bit.
ok jsing
|
|
Error check BIO_new() both times it is used, drop unused j variable,
Error check BIO_printf() call and turn the whole thing into single exit.
Prompted by a diff by Niels Dossche
ok jsing
|
|
|