| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The degree made some sense when EC2M was a thing in libcrypto. Fortunately
that's not the case anymore. The order handler never made sense.
ok jsing
|
|
|
|
| |
requested by jsing
|
|
|
|
| |
requested by jsing
|
|
|
|
|
|
| |
This is another bit of indirection that makes this code so hard to follow.
ok jsing
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
BN_reciprocal() is only called by BN_div_recp() which in turn is only
called by BN_mod_mul_reciprocal(). So use this order and make the first
two static.
|
|
|
|
|
|
|
| |
This is usually method specific, so remove the indirection and call the
appropriate blinding function directly.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only used by ec_points_make_affine(), which is only used by the
wNAF multiplication, which is only used by ECDSA. We can afford computing
that one once per ECDSA verification given the cost of the rest of this.
Thus, the field_set_to_one() member disappears from the EC_METHOD and the
mont_one member disappears from EC_GROUP and with it all the complications
when setting/copying/freeing the group.
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That the BN-driven EC code uses Jacobian projective coordinates as an
optimization is an implementation detail. As such this should never have
leaked out of the library as part of the public API. No consumer should
ever care and if they do they're doing it wrong. The only port that cares
is one of those stupid little perl modules that expose all the things and
transform terrible OpenSSL regress tests into similarly horrible Perl.
In practice, only affine coordinates matter (perhaps in compressed form).
This prunes two more function pointers from EC_GROUP and prepares the
removal of the field_set_to_one() method which is now only used in
ec_points_make_affine().
ok jsing sthen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only way to get an EC_GROUP or an EC_POINT is by calling the relevant
_new() function and to get rid of it, something must call _free(). Thus we
can establish the invariant that every group has Weierstrass coefficients
p, a, b as well as order and cofactor hanging off it. Similarly, Every
point has allocated BIGNUMs for its Jacobian projective coordinates.
Unfortunately, a group has the generator as an optional component in
addition to seed and montgomery context/one (where optionality makes
more sense).
This is a mostly mechanical diff and only drops a few silly comments and
a couple of unnecessary NULL checks since in our part of the wrold the
word invariant has a meaning.
This should also appease Coverity who likes to throw fits at calling
BN_free() for BIGNUM on the stack (yes, this is actually a thing).
ok jsing
|
|
|
|
| |
ok jsing kn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can set custom sign and verify handlers on an RSA method (wihch is
used to create RSA private and public key handles). However, even if you
set them explicitly with RSA_meth_set_{sign,verify}(3), these handlers
aren't used for the sake of "backward compatibility" (with what?). In order
to use them, you need to opt your objects into using the custom methods
you set by setting the RSA_FLAG_SIGN_VER flag.
OpenSSL 1.1 dropped this requirement and therefore nobody sets this flag
anyore. Like most of the mechanically added accessors, almost nothing
uses them, but, as found by kn, the yubco-piv-tool does. This resulted
in a public key being passed to rsa_private_encrypt(), which of course
doesn't end well.
So follow OpenSSL 1.1 and drop this muppetry. This makes kn's problem
with yubico-piv-tool go away.
ok jsing kn
|
|
|
|
|
| |
Reflow the comment to avoid some very unfortunate line wraps. "Note that"
is like "literally" a bunch of generally useless noise and best omitted.
|
| |
|
|
|
|
| |
Review feedback by jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
There is only one caller, EC_GROUP_free(), so inline the relevant free
calls there and dispose of a few layers of indirection.
ok jsing
|
|
|
|
|
|
|
|
| |
For both in-tree methods these are just complicated ways of zeroing part
of the group object. The group is allocated with calloc(), so it's all
entirely pointless.
ok jsing
|
| |
|
|
|
|
| |
The code supporting it was removed in April 2023.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because that's what OpenSSL 1.1 suggests. Even though that "unification"
doesn't really simplify anything but is more akin to repainting the bikeshed,
at least it doesn't cause any additional harm, so keeping recommendations
consistent may reduce the risk of code breaking in the future.
Provide an example of decryption with AES-CCM in addition to the
example of encryption already in place, because there are a number
of subtle and non-obvious differences that users have to pay
attention to.
Both ideas originally suggested by tb@.
|
|
|
|
|
|
|
|
|
| |
The only caller passes in OBJ_BSEARCH_FIRST_VALUE_ON_MATCH, so the
condition involving this flag is always true. On the other hand,
while OBJ_BSEARCh_VALUE_ON_NOMATCH is left unset hence the condition
involving this flag is also true (since negated).
ok jsing
|
|
|
|
|
|
|
| |
internal_find() was a generalization needed for sk_find_ex(), which was
removed a while ago.
ok jsing
|
|
|
|
|
| |
While here, also add a (c) line for tb@ because he added Copyright-worthy
amounts of text to this page during the last two years.
|
|
|
|
|
|
| |
The sentence about X509_EXTENSION_get_critical(3) in the DESCRIPTION
contained broken grammar or at least broken punctuation, and more
importantly, redundant and misplaced information. While he, shorten it.
|
|
|
|
|
| |
Sort the list of decoding functions alphabetically by extension type.
List the printing functions that are already documented.
|
| |
|
|
|
|
| |
ok jsing
|
|
|
|
|
| |
Now that it lives in a .c file, there's no need to point out that it is
non-public...
|
| |
|
|
|
|
|
|
|
|
|
| |
forgotten in rev. 1.3 on July 13 this year.
No library bump and no ABI change because libcrypto.so.55.0 did not
export the symbol because it wasn't in Symbols.list.
Found in a partial code audit focusing on X509V3_EXT_METHOD objects.
|
| |
|
|
|
|
|
|
|
|
| |
Unclear why this ever had to be made public since it's only used in a
single file. Anyway, nothing uses this, so remove it.
This went through a full bulk
pointed out by/ok schwarze
|
|
|
|
|
|
|
|
| |
These were used in x509_bitst.c and x509_ia5.c for populating tables that
have been expanded a long time ago. Nothing uses them, so remove them.
This went through a full bulk
pointed out by/ok schwarze
|
|
|
|
|
| |
Only security/xca uses it for no good rean. It can use BIT_STRING_BITNAME
if it really needs to.
|
|
|
|
|
|
|
|
|
|
| |
LibreSSL has removed support for dynamically allocated custom extension
methods. The mysterious CTX_DEP define was part of an experimental code
dump and that part of the experimental code was never shown hence never
reviewed.
This went through a full amd64 bulk
noticed by/ok schwarze
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the internal subroutine X509V3_add_value(), which could result
in silently losing part of the input data on memory exhaustion.
I independently rediscovered this bug while writing the documentation,
then noticed after fixing it that Zhou Qingyang <zhou1615 at umn dot edu>
fixed it in essentially the same way in OpenSSL 3 (commit bcd5645b
on Apr 11 02:05:19 2022 +0800), but it wasn't backported to the
OpenSSL 1.1.1 branch.
OK tb@
|
| |
|
|
|
|
|
|
| |
correspond to an extension method.
ok schwarze
|
| |
|
|
|
|
|
| |
fix the name of its last parameter in the SYNOPSIS to match the DESCRIPTION,
and let the .Dt argument match the file name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I admit this is unusually long for a manual page. But that's not my fault
as a documentation author. An example in a manual page ought to be minimal
to show what needs to be demonstrated, and this example is minimal in that
sense. Making it shorter without loosing important aspects does not seem
possible.
When an API is poorly designed, one of the consequences is that that
documentation becomes harder to understand and often longer - in this
case to the point of becoming outright intimidating. If people dislike
that, they should design better APIs in the first place rather than
blasting the poor manual page for being too long or too complicated.
OK tb@
|