| Commit message (Collapse) | Author | Files | Lines |
|---|
|
It does *not* "work in the same way" as EVP_PKEY_new_raw_private_key(3)
but merely arrives at the same end result after doing lots of
cumbersome and unnecessary work - and on top of that, it only works
for EVP_PKEY_HMAC.
|
|
parameters that can be controlled with EVP_PKEY_CTX_ctrl(3).
But rather than providing a detailed despription, instead
point to what application programs should use instead and explain
why using the control constant directly would be a particularly bad
idea in this case.
|
|
|
|
ok beck
|
|
|
|
|
|
There is currently no sane way of getting your hands on the common name or
subject alternative name of the peer certificate from libtls. It is possible
to extract it from the peer cert's PEM by hand, but that way lies madness.
While the common name is close to being deprecated in the webpki, it is
still the de facto standard to identify client certs. It would be nice to
have a way to access the subject alternative names as well, but this is a
lot more difficult to expose in a clean and sane C interface due to its
multivaluedness.
Initial diff from henning, with input from beck, jsing and myself
henning and bluhm have plans of using this in syslogd.
ok beck
|
|
because they are intended as internal, and applications are supposed to use
the documented aliases DH, DSA, EC_KEY, and RSA from ossl_typ.h instead.
|
|
because they are completely unused by anything.
|
|
that are obsolete after PBE was mostly removed from LibreSSL.
|
|
|
|
that are only used for GOST.
|
|
undocumented because they are only used by the function X509_certificate_type()
which is deprecated and will eventually be deleted.
|
|
because LibreSSL does not support RC5 and because these constants
are almost unused in the wild.
|
|
and document them properly in their own manual page, including the control
commands EVP_CTRL_SET_RC2_KEY_BITS and EVP_CTRL_GET_RC2_KEY_BITS that were
so far undocumented.
Arguably, the main benefit is another small step making the important,
but still obese EVP_EncryptInit(3) manual page more palatable.
|
|
Not that this would be particularly important, but i had to look
at the code anyway while completing the EVP documentation.
|
|
|
|
|
|
discussed with jsing
|
|
This refactors the wNAF multiplication further and introduces a small API
that manages the wNAF digits for bn and the multiples of digit * point in
a single struct that is initialized and freed in two API calls in the main
function, ec_wNAF_mul(). This way the main algorithm is no longer cluttered
with logic to keep various arrays in sync, helper functions calculating the
wNAF splitting of bn and multiples of the point do not need to deal with
memory management, and a pair of accessors obviates previously missing
bounds checking.
At this point we have reached a relatively clean and straightforward wNAF
implementation that fits precisely the purpose needed in libcrypto, i.e.,
ECDSA verification instead of being generalized and optimized to the max
for no good reason apart from endowing the author with an academic degree.
Popper's famous maxim "if you can't say it clearly, keep quiet, and keep
working until you can" very much applies to code as well. In other words,
shut up and hack (and don't pour too much energy into commit messages, tb).
ok jsing
|
|
and EVP_CIPHER_CTX_init(3) after tb@ changed these to OpenSSL 1.1 semantics
in evp.h rev. 1.124 on March 2 this year.
|
|
because tb@ deleted almost all functions documented there from the API
in evp.h 1.127 on March 2 this year, but move the functions
EVP_PKEY_CTX_set_data(3) and EVP_PKEY_CTX_get_data(3) that we still
support to EVP_PKEY_keygen(3), because that page already documents
EVP_PKEY_CTX_set_app_data(3) and EVP_PKEY_CTX_get_app_data(3).
|
|
All three functions documented in this page were deleted from the API
by tb@ in evp.h rev. 1.136 on August 31 this year.
|
|
All the functions documented in this page were deleted from the API
by tb@ in evp.h rev. 1.126 on March 2 this year.
|
|
This provides a SHA-1 assembly implementation for amd64, which uses
the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This
provides a 2-2.5x performance gain on some Intel CPUs and many AMD CPUs.
ok tb@
|
|
It's so non-obvious that even i had to do some research to find out.
Source: The file "doc/ssleay.doc" from SSLeay 0.8.1b,
see for example OpenSSL commit d02b48c6 on Dec 21, 1998.
|
|
Looks like I applied the diff to a dirty tree and didn't notice.
|
|
|
|
We match curve parameters against the builtin curves and only accept
them if they're encoding a curve known to us. After getting rid of the
wtls curves, some of which used to coincide with secp curves (sometimes
the wrong ones), the nid is unambiguous. Setting the nid has no direct
implications on the encoding.
This helps ssh avoid doing ugly computations during the key exchange
for PEM keys using this encoding.
ok djm joshua jsing
|
|
|
|
Rename it to DSA_prime_checks and add an XXX comment mentioning that
we could reduce the number of rounds thanks to BPSW. There are no
plans of changing that as DSA is on its way out.
discussed with miod
|
|
It aliases BN_is_prime(), which was removed in April 2023.
makes sense to miod
|
|
|
|
constants after these have been marked as intentionally undocumented;
they are internal to the library and unused in the wild
|
|
that are internal to the library and unused in the wild
|
|
that are only intended for internal use and unused in the wild
|
|
|
|
Makes the setting and getting of detached signatures more symmetric
and avoids a NULL access.
ok jsing
|
|
This matches the other members of X509 and is what's used everywhere else.
ok miod
|
|
|
|
As already done for SHA-256 and SHA-512, replace the perlasm generated
SHA-1 assembly implementation with one that is actually readable. Call the
assembly implementation from a C wrapper that can, in the future, dispatch
to alternate implementations. On a modern CPU the performance is around
5% faster than the base implementation generated by sha1-x86_64.pl, however
it is around 15% slower than the excessively complex SSSE2/AVX version that
is also generated by the same script (a SHA-NI version will greatly
outperform this and is much cleaner/simpler).
ok tb@
|
|
This should really have been using SECP 160R2, not SECP 160R1. Of course
this means in particular that nobody ever used this curve, at least not
against another implementation than OpenSSL. Quasi-monocultures are
poisonous whether the monopolist is benevolent and competent or not.
|
|
Upstream decided that this nonsense was worth an ABI break and added stuff
to the X509_CTX so they could hang the issuer's public key off it so that
they could adjust the key identifiers as needed. Let's avoid that and do
it the slightly less nasty way by updating the AKI and SKI as needed.
We only do this when force pubkey is in place so we don't change the
semantics of the batshit crazy config language that nobody understands.
ok job
|
|
from Kenjiro Nakayama
|
|
|
|
|
|
with job
|
|
Like most of the "group" methods these are shared between Montgomery
curves and simple curves. There's no point in five methods hanging off
the EC_METHODS struct whne they can just as well be inlined in the
public API. It makes all files involved shorter...
ok jsing
|
|
While there likely won't be enough BNs already available in the ctx, and
thus it won't greatly reduce the amount of allocated BNs, it simplifies
the exit path quite a bit.
review feedback from jsing
|
|
It is unclear how the original code was supposed to work. It clearly
missed a few corner cases (like handling points at infinity correctly)
and the badly mangled comment that was supposed to display a binary
search tree didn't help at all.
Instead do something much more straightforward: multiply all the non-zero
Z coordinates of the points not at infinity together, keeping track of the
intermediate products. Then do a single expensive modular inversion before
working backwards to compute all the inverses. Then the transformation from
Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1)
becomes cheap. A little bit of care has to be taken for Montgomery curves
but that's very simple compared to the mess that was there before.
ok jsing
This is a cleaned up version of:
commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae
Author: Bodo Moeller <bodo@openssl.org>
Date: Fri Aug 1 17:18:14 2014 +0200
Simplify and fix ec_GFp_simple_points_make_affine
(which didn't always handle value 0 correctly).
Reviewed-by: emilia@openssl.org
|
