| Commit message (Collapse) | Author | Files | Lines |
|
We received reports that the too generic internal ecdsa_{sign,verify}()
symbol names clash in some static links. The naming here is annoying
because the EC_KEY_METHOD amalgamated the no longer existing ECDH and
ECDSA methods which themselves had poorly chosen method names, still
reflected in public API.
There are various messes here. The ECDSA verify methods are declared
in ec_local.h, whereas the ECDSA sign methods are in ecdsa_local.h
(which is itself pretty useless and really only about EC_KEY_METHOD).
I therefore merged the ECDSA method declarations into ec_local.h and
deleted ecdsa_local.h since I see no real benefit to the latter.
ecdsa.c needs ec_local.h anyway. Having the method declarations next
to EC_KEY_METHOD seems sensible. I left the order as it was, matching
ecdsa.c. The eckey_compute_pubkey() prototype should probably be moved
down.
With one exception I just added an ec_key_ prefix. This leads to a
a repetition of 'key' in ec_key_ecdh_compute_key() which I chose to
live with because it matches the public ECDH_compute_key() (mostly
used by SSH implementations). The exception is ec_key_generate_key()
where I expanded the gen() leading to another _key repetition but
this then matches EC_KEY_generate_key().
Thanks to Rosen Penev for reporting and sending an initial diff.
See also https://github.com/gsliepen/tinc/issues/478
ok jsing
|
|
|
|
The need for this compile time option enabling point compression for
binary curves despite patent issues has been removed in openssl 1.0.0
(released in 2010).
[It's really difficult to count the number of bad ideas in the above.]
|
|
|
|
This improves the test coverage of make_addressRange() where there is an
annoyance with unused bits in the RFC 3779 ASN.1 encoding versus trailing
ones in the network encoding that the X509v3_addr_add_range() API expects.
|
|
pointed out by/ok dlg
|
|
|
|
|
|
promise levels. You must be running a kernel at least 4 days old.
Soon, another commit will happen that breaks compatibility even further,
and you'll need new static binaries and new libc.so, along with a new
kernel. This removes an old pledge design decision which is weak.
Long discussions with david leadbeater and beck
|
|
Replace memcmp() with timingsafe_memcmp() when comparing the
re-encrypted ciphertext.
FIPS 203 Section 6.3 defines this comparison result as a secret piece
of intermediate data that must not be revealed in any form.
ok tb
|
|
argument flags. I think this correctly replaces "tmppath" with an
unveil.
|
|
The OID 2.99999.3 is not required for x509 output handling and
is not referenced elsewhere. Remove the OBJ_create() call.
ok tb jsing
|
|
In the x509 command, `-text` output is not written to the file specified
by `-out`, whereas in other OpenSSL/LibreSSL subcommands it is.
With this change, STDout is removed, and `-text` output is written
entirely to the file specified by `-out`, making the behavior consistent
with other subcommands.
Fix https://github.com/libressl/portable/issues/1228
ok tb jsing
|
|
|
|
jsing prefers doing all computations first and comparing at the end. This
means we do more work when we fail and no longer (ab)use err as an out label.
Also split out one more helper.
ok jsing
|
|
Instead of relying on i2c_ASN1_BIT_STRING() to determine the "unused"
bits on encoding, set them explicitly in abs->flags via a call to
asn1_abs_set_unused_bits(). This means ASN1_STRING_FLAGS_BITS_LEFT is
now set on a bit string, which was previously explicitly cleared.
This also means that the encoding of a non-zero ASN1_BIT_STRING
populated by setting the bits individually will now go through the
if (a->flags & ASN1_STRING_FLAG_BITS_LEFT) path in i2c_ASN1_BIT_STRING().
The most prominent usage of this function is in X.509 for the keyUsage
extension or the CRL reason codes. There's also the NS cert type, TS
PKIFailureInfo and general BITLIST config strings.
The reason for the truncation logic comes from the DER for NamedBitLists
X.690, 11.2.2 below:
X.680, 22.7:
When a "NamedBitList" is used in defining a bitstring type ASN.1
encoding rules are free to add (or remove) arbitrarily any trailing 0
bits to (or from) values that are being encoded or decoded. Application
designers should therefore ensure that different semantics are not
associated with such values which differ only in the number of trailing
0 bits.
X.690, 11.2.2
Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 22.7, applies, the bitstring
shall have all trailing 0 bits removed before it is encoded.
Note 1 - In the case where a size constraint has been applied, the
abstract value delivered by a decoder to the application will be one of
those satisfying the size constraint and differing from the transmitted
value only in the number of trailing zero bits.
Note 2 - If a bitstring value has no 1 bits, then an encoder shall
encode the value with a length of 1 and an initial octet set to 0.
ok kenjiro (on an earlier version) jsing
|
|
Found the same fix from davidben in BoringSSL as well (https://boringssl-review.googlesource.com/c/boringssl/+/87927). OpenSSL appears to have accidentally changed the semantics here with the HAS_PREFIX macro, which appears to be incorrect.
discussed w/ tb@ & beck@
|
|
OK on previous diff concept sthen@
Suggestions, feedback and OK current diff tb@
|
|
|
|
If str is a const unsigned char * rather than a char *, we can get away
with a single cast and do not need to cast away const either. Reduce the
scope of tmpbuf and ctmpbuf (now p) while there.
ok kenjiro
|
|
While normal calls return 0 for error and npubk for success, there is a
case where it returns the usual 1/0 thing. Make that explicit.
Prompted by a report by Niels Dossche
ok jsing kenjiro
|
|
This has been incorrectly documented since forever. The function only ever
returned 0/1.
ok jsing kenjiro
|
|
ok jsing kenjiro
|
|
The subsequent EVP_{Decrypt,Encrypt}Init_ex() calls already do that.
pointed out by jsing
|
|
Explicitly compare pointers against NULL, turn the function into single
exit, add hint at why npubk <= 0 or pubk == NULL are a success path:
The documentation briefly explains that EVP_OpenInit() and EVP_SealInit()
is able to initialize the EVP_CIPHER_CTX in two steps exactly like the
EVP_CipherInit_ex() API they wrap: the first call with non-NULL cipher
(aka type) only sets the cipher on the ctx, then it returns to allow
callers to customize the EVP_CIPHER_CTX, and a second call with
cipher == NULL skips the initialization and finishes the ctx setup
by setting key and iv.
Prompted by a report by Niels Dossche.
ok jsing kenjiro
|
|
It is documented that EVP_SealInit() returns 0 on error. So -1 is wrong.
Reported by Niels Dossche
ok jsing kenjiro
|
|
Explicitly compare pointers against NULL, turn the function into single
exit and explain why priv == NULL is a success (hint: muppet API).
Prompted by a report by Niels Dossche.
ok jsing kenjiro
|
|
A malformed v2 signing cert can lead to a type confusion, and the result
is a read from an invalid memory address or NULL, so a crash. Unlike for
OpenSSL, v1 signing certs aren't affected since miod fixed this in '14.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-69420.
ok jsing
|
|
A type confusion can lead to a 1-byte read at address 0x00-0xff, so a
crash.
Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-22795
ok jsing
|
|
Avoids a NULL pointer dereference triggerable by a malformed PCKS#12 file.
From Luigino Camastra via OpenSSL (CVE-2025-69421)
ok jsing
|
|
discussed with jsing
|
|
|
|
|