| Commit message (Collapse) | Author | Files | Lines |
|
These annoying and careless inconsistencies were introduced when const
was sprinkled everywhere without rhyme or reason.
|
|
|
|
|
|
fixes in particular ./check_complete.pl pkcs7
|
|
|
|
These are safe to call concurrently and they don't modify the memory
region pointed to by the pkey - they only bump the refcount of the
key hanging off of it. The returned "legacy" key has to be handled with
care in threaded constexts, so it is handed back as non-const. This also
matches what EVP_PKEY_get0() always had.
This way our signature is identical to BoringSSL's and doesn't cause
compiler warnings in code that overuses const because one of the many
API incoherencies added by OpenSSL 3 was to turn get0 into a function
that takes and returns const while leaving get1 as it was.
dlg agrees
ok kenjiro
|
|
These have been taking a const pkey ever since they were added in
OpenSSL 1.0.0.
|
|
While EVP_CIPHER_CTX_ctrl() can return a negative value this can't
actually happen currently as all ciphers with EVP_CIPH_CTRL_INIT set
normalize the EVP_CTRL_INIT return value to boolean in their ctrl()
methods. Still, this check looks weird in grep, so align it.
ok beck kenjiro
|
|
ok job kenjiro
|
|
issuerUID and subjectUID are a curiosity introduced in X.509v2 before
extensions were a thing. Their purpose is to help distinguishing certs
with identical subject. They are rarely used and are MUST NOT use in
the CA/BF baseline requirements. They do occasionally show up in test
certificates and it is confusing that openssl x509 silently ignores
them. Their encoding also makes them relatively hard to spot in the
output of asn1 parsing tools.
The output is identical to OpenSSL < 3 and BoringSSL, but due to some
weird tweaks added leading up to OpenSSL 3 their output is no longer
compatible with that. It is not entirely correct anyway. Since it is
a (not further specified) bit string, you shouldn't be ignoring its
unused bits...
The X509_FLAG_NO_IDS flag has no effect for CSRs.
discussed with beck
ok job kenjiro (on an earlier version)
|
|
|
|
this drives me nuts when i want to print something out of what's already
const. casting it works, but feels gross.
ok guenther@ tb@ deraadt@
enh says this is already in bionic/glibc/musl
|
|
Provide an assembly implementation of SHA-1 for aarch64 using the ARM
Cryptographic Extension (CE). This results in around a 2x speed up for
larger block sizes.
ok tb@
|
|
Provide gcm128_amd64.c and gcm128_i386.c, which contain the appropriate
gcm128 initialisation and CPU feature tests for the respective platform.
This allows for all of the #define spagetti to be removed from gcm128.c
and removes one of the two remaining consumers of crypto_cpu_caps_ia32().
ok tb@
|
|
Since we always initialise the gmult/ghash function pointers, use the same
implementaion of gcm_mul() and gcm_ghash(), regardless of the actual
underlying implementation.
ok tb@
|
|
|
|
ok tb@
|
|
ok tb@
|
|
Like CTR, the mode implementation for GCM has two variants - rather than
using multiple variants (one for AES-NI, another for non-AES-NI),
consistently use CRYPTO_gcm128_{en,de}crypt_ctr32() with the
aes_ctr32_encrypt_internal() function added for CTR mode.
This lets us remove the AES-NI specific code, AES-NI specific EVP_CIPHER
methods and the ctr function pointer from EVP_AES_GCM_CTX.
ok tb@
|
|
The mode implementation for CTR has two variants - one takes the block
function, while the other takes a "ctr32" function. The latter is expected
to handle the lower 32 bits of the IV/counter, but is not expected to
handle overflow. The AES-NI implementation for CTR currently uses the
second variant.
Provide aes_ctr32_encrypt_internal() as a function that can be replaced on
a machine dependent basis, along with an aes_ctr32_encrypt_generic()
function that provides the default implementation and can be used as a
fallback. Wire up the AES-NI version for amd64 and i386, change
AES_ctr128_encrypt() to use CRYPTO_ctr128_encrypt_ctr32() (which calls
aes_ctr32_encrypt_internal()) and remove the various AES-NI specific
EVP_CIPHER methods for CTR.
Callers of AES_ctr128_encrypt() will now use AES-NI, if available.
ok tb@
|
|
MAXKB was added in OpenSSL commit deb2c1a1 and appears to have never been
used, while MAXKC (originally RIJNDAEL_MAXKC) stopped being used in that
same commit. MAXNR is also unused - AES_MAXNR exists in the public
header.
ok tb@
|
|
|
|
Manually counting letters in const strings is ... suboptimal.
ok beck jsing
|
|
From David Leadbeater
|
|
From David Leadbeater with a report_tls tweak by me
ok jsing
|
|
requested by jsing
|
|
|
|
|
|
These now end up in aesni_encrypt() via AES_encrypt(), when appropriate.
ok tb@
|
|
These now end up in aesni_encrypt() via AES_encrypt(), when appropriate.
ok tb@
|
|
These now end up in aesni_cbc_encrypt() via AES_cbc_encrypt(), when
appropriate.
ok tb@
|
|
avoids unnecessary diff in output between runs
|
|
ok beck
|
|
The various methods can now use the regular init key functions, since the
call to AES_set_{en,de}crypt_key() will be routed to the AES-NI
implementation, if supported.
ok tb@
|
|
Currently, the AES-NI code is only integrated into EVP - add code to
integrate AES-NI into AES. Rename the assembly provided functions and
provide C versions for the original names, which check for AES-NI support
and dispatch to the appropriate function. This means that the AES_* public
API will now use AES-NI, if available.
ok tb@
|
|
This indicates if AES-NI is available via CRYPTO_CPU_CAPS_I386_AES.
ok tb@
|
|
ok tb@
|
|
Requires py3-tlsfuzzer-20250516 to work
|
|
|
|
per X9.62, F.3.4.b. This ensures that the table entries in ec_curves.c for
the NIST curves P-224, P-256, P-384, and P-521 are internally consistent
and in particular that the seed is correct.
|
|
This was changed a bit more than two years ago.
|
|
10% of our manual pages using this macro employed useless quoting anyway.
Remove these quotes such that they do not incite fear, uncertainty,
and doubt in developers who happen to look at these pages.
jmc@ and tb@ agree with the direction.
|
|
care of doing that include.
|
|
claiming that the "add" functions add anything. Indicate that they
are mostly NOOPs nowadays, but without being overly specific.
Also, more explicitly discourage abusing OpenSSL_add_all_algorithms(3)
for loadiing a configuration file.
Guidance and OK tb@.
|
|
mistaknely made the write buffer usable even if the stream is read
mode. See the change of lib/libc/stdio/fpurge.c,v 1.11.
|
|
|
|
are no longer public, so delete their manual pages.
OK tb@
|
|
descriptions of CMS_REUSE_DIGEST, PKCS7_REUSE_DIGEST, SMIME_BINARY,
and SMIME_CRLFEOL and some improved wordings from that former page to
SMIME_write_CMS(3) and SMIME_write_PKCS7(3), with some further polishing.
Feedback and OK tb@.
|
|
|
|
and since SMIME_write_ASN1(3) is no longer public,
replace the .Xr to it with some other pointers.
OK tb@
|