Re: Upgrading OpenSSL on Windows 10
> From: openssl-users on behalf of > Steven_M.irc via openssl-users > Sent: Monday, November 21, 2022 15:56 > However, I am running Windows 10, and since (unlike Linux) every piece of > software outside of Windows itself > needs to be updated individually, I don't know how to track down every single > application that might be using > OpenSSL and make sure that the copy of OpenSSL it uses is up-to-date. You don't. There may be applications that have OpenSSL linked statically, or linked into one of its own DLLs, or just with the OpenSSL DLLs renamed. > As many of you would know, under repository-based systems (such as most Linux > distros), this would not be an > issue as I could update every single application (system or non-system) at > once. This is not true in the general case. There are applications which are available on Linux which do not use the distribution's package manager. There are applications which use their own OpenSSL build, possibly linked statically or linked into one of their own shared objects or with the OpenSSL shared objects renamed. Linux distributions have not magically solved the problem of keeping all software on the system current. Back to Windows: It is possible, with relatively little effort, to find all the copies of the OpenSSL DLLs under their usual names on a system, and then glean from them their version information. With significantly more effort, you can search for exported OpenSSL symbols within third-party binaries, which will detect some more instances. With quite a lot of additional effort, you can winkle out binaries which contain significant portions of code matching some OpenSSL release (see various research efforts on function-point and code-block matching, and compare with alignment strategies in other fields, such as genomics). If your definition of "OpenSSL in an application" is not too ambitious, this might even be feasible. But to what end? Each application will either be well-supported, in which case you can find out from the vendor what OpenSSL version it contains and whether an update is available; or it is not, in which you'll be out of luck. This is true of essentially every software component, most of which are not as well-maintained or monitored as OpenSSL. Modern software development is mostly a haphazard hodgepodge of accumulating software of uncertain provenance and little trustworthiness into enormous systems with unpredictable behavior and failure modes. I'm not sure OpenSSL versions should be particularly high on anyone's priority list. What are you actually trying to accomplish? What's your task? Your threat model? -- Michael Wojcik
Upgrading OpenSSL on Windows 10
Hi All, A few weeks ago I sent this e-mail to the group: https://mta.openssl.org/pipermail/openssl-users/2022-November/015613.html I received a couple of replies, but sadly I have been too busy to respond to them. Regardless, I need a bit more information please. In one of the replies, Viktor said "Just upgrade any affected systems and you'll be fine.". However, I am running Windows 10, and since (unlike Linux) every piece of software outside of Windows itself needs to be updated individually, I don't know how to track down every single application that might be using OpenSSL and make sure that the copy of OpenSSL it uses is up-to-date. As many of you would know, under repository-based systems (such as most Linux distros), this would not be an issue as I could update every single application (system or non-system) at once. For those of you who may be thinking "but Windows doesn't use OpenSSL"; when the latest OpenSSL vulnerabilities were discovered I asked a Windows IRC channel whether or not Windows uses OpenSSL, the reply was that Windows itself does not use it, but many applications running on Windows do. Thank you all for your time.
Re: X52219/X448 export public key coordinates
Thanks for the explanation, that probably makes sense.
Thank you
Matt
From: Kyle Hamilton
Date: Monday, 21 November 2022 12:46
To: ORNEST Matej - Contractor
Cc: openssl-users
Subject: Re: X52219/X448 export public key coordinates
The reason has to do with the type of curve representation. X25519 is typically
represented in (I believe, but I'm not an expert and I haven't looked at the
primary sources recently so take this with a grain of salt) Montgomery form.
Its digital signature counterpart Ed25519 uses the same curve represented in
Edwards form.
Conversely, the NIST curves are in Weierstrass form. The EC_KEY interface deals
solely with Weierstrass form.
To my understanding, you can convert any curve to any representation. However,
different forms can be acted on with different values at different levels of
efficiency, which is why the different forms exist.
I hope this helps!
-Kyle H
On Fri, Nov 18, 2022, 11:47 ORNEST Matej - Contractor via openssl-users
mailto:openssl-users@openssl.org>> wrote:
Yeah, of course, sorry for the typo. I’ve already found a solution that seems
to be working by using EVP_PKEY_get_raw_public_key() for these types of curves.
I was confused why it’s not working with EC_KEY interfaces though it’s type of
elliptic curve. Then I found somewhere that it’s implemented outside the
context of EC. It’s not clear to me why but I believe there’s a good reason for
it.
Anyway, thanks for your answer!
Regards
Matt
On 18. 11. 2022, at 17:13, Kyle Hamilton
mailto:aerow...@gmail.com>> wrote:
X25519?
On Mon, Nov 14, 2022, 05:23 ORNEST Matej - Contractor via openssl-users
mailto:openssl-users@openssl.org>> wrote:
Hi all,
I need to implement support for X52219/X448 for DH key exchange (and
Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export public
key for DH exchange in form of DER encoded chunk in form
tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY and
encode it as needed. I understand that those key types differs from EC types in
way that I need just X coordinate and a flag bit to reconstruct the key, but
still, how do I get the X coordinate?
My solution works for all other EC types such as SecpX and Brainpool families,
but not for X52219/X448 keys and I do not completely understand why.
Specifically when I decode public key previously encoded with i2d_PUBKEY() to
EVP_PEKY and try to get EC_KEY by calling EVP_PKEY_get0_EC_KEY(), it returns
NULL and issues an error that it’s not an EC key…
I’m using following code:
EVP_PKEY *key = … // Decode from DER encoded public key
if(key != nil) {
EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);
/// When X52219 or X448 key is passed, ecKey is NULL
if(ecKey != NULL) {
const EC_POINT *point = EC_KEY_get0_public_key(ecKey);
const EC_GROUP *group = EC_KEY_get0_group(ecKey);
if(point != NULL && group != NULL) {
BIGNUM *bnX = BN_new();
BIGNUM *bnY = BN_new();
if(EC_POINT_get_affine_coordinates(group, point, bnX, bnY,
NULL)) {
char *hexX = BN_bn2hex(bnX);
char *hexY = BN_bn2hex(bnY);
// Convert to custom data structures
…
}
BN_free(bnX);
BN_free(bnY);
}
}
}
Is there any way how to export those key types in desired format? I’m using
OpenSSL version 1.1.1q.
Thank you very much for any hint
Matt
