| Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is a remnant from s390x assembly.
|
|
Change aes_cbc_cipher() to call AES_cbc_encrypt() directly, rather than
via the stream.cbc function pointer. Remove stream.cbc since it is no
longer used. Also provide a separate aes_cbc_init_key() function which
makes this standalone and does not require checking mode flags.
ok joshua@ tb@
|
|
ok jsing@
|
|
No change in generated assembly.
|
|
Instead of using size_t and a PACK macro, store the entries as uint16_t and
then uncondtionally left shift 48 bits. This gives a small performance gain
on some architectures and has the advantage of reducing the size of the
table from 1024 bits to 256 bits.
ok beck@ joshua@ tb@
|
|
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@
|
|
|
|
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@
|
|
Since struct gcm128_context is not exposed via a public header, there is no
way CRYPTO_gcm128_init() can actually be used properly. Instead, use
CRYPTO_gcm128_new() and CRYPTO_gcm128_free_bird()^WCRYPTO_gcm128_release()
(naming consistency is apparently hard).
|
|
From Ross L Richardson
|
|
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 CMS code doesn't support RFC 5083/5084 authenticated enveloped data
and outputs garbage that even itself can't decrypt for a reason that I
have not tried to pinpoint. So refuse using AEAD ciphers and AES XTS for
enveloped data from the cms "app" and throw an error pointing out that
this isn't supported.
OpenSSL have since added incorrect support for AuthEnvelopedData (ASN.1
and code review are hard), so doing this right will need both correct and
interoperable code, which I doubt anyone will bother to write anytime soon.
Reported by Ben Cooper in https://github.com/libressl/portable/issues/1157
ok beck 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
|
|
ok jsing
|
|
Remove the old x509name test and its Makefile rule. Its logic has
been fully integrated into x509_name_test.c using a new table-driven
approach. Each x509 name entry is added and validated step by step,
checking both the string representation produced by X509_NAME_print_ex()
and the internal RDN set structure.
This makes the test easier to extend and maintain, and eliminates the need
for an external .expected file or output diff.
From Kenjiro Nakayama (with tiny tweaks)
|
|
|
|
This simplifies the test in portable and makes the whole thing a bit
less ugly overall.
From Kenjiro Nakayama with minor tweaks by me
|
|
|
|
|
|
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
|
|
From Kenjiro Nakayama
|
|
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
|
|
The next commit will remove the kludge for compatibility of Apache with
older libressl, so remove the corresponding regress coverage and only
check that PSK is the last extension.
|
|
|
|
|
