| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Prompted by a diff by Kenjiro Nakayama
ok jsing
|
| |
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
pointed out by djm a while back
|
|
|
|
|
|
|
| |
These three are still used in about half a dozen ports. All the others are
unused.
ok jsing
|
| |
|
|
|
|
|
|
|
| |
These are now only used in libcrypto. They should never have been in a
public header in the first place.
ok jsing
|
|
|
|
| |
ok jsing
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The _cb() variants were only documented as intentionally undocumented.
Be that as it may, they left the building more than a year ago.
|
|
|
|
| |
ok jsing
|
| |
|
| |
|
| |
|
|
|
|
| |
Makes upcoming changes in regress less ugly.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ok jsing
|
| |
|
|
|
|
|
|
|
| |
This will need reworking (especially deduplicating) anyway, but it doesn't
hurt now.
From Kenjiro Nakayama
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
All supported releases of LibreSSL ensure that the corresponding callbacks
are called in a predefined order rather than honoring the order in which a
client sends its extensions. Therefore the ALPN callback for apache-httpd's
virtual host setups can rely on SNI information being available and we no
longer need to work around this on hte client side. Cuts the amount of code
needed for tlsext randomization in half.
ok jsing
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
-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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
ok beck@ tb@
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|