UnsupportedAlgorithm: X25519 is not supported by this version of OpenSSL. #8837
Comments
|
You need to make sure that python2.7 is linked to that new
openssl. My guess is that your python version is still using
the 1.0.2 version.
|
|
i get latest pythone 2.7 and recompile it for using system openssl: but problem is not solved |
|
I suggest you contact the python people in that case.
|
|
I had the same problem on gentoo. Solved it by rebuilding dev-python/cryptography |
|
i install latest version(by pip install/upgrade) of packages devops-tools and cryptography: and but problem is not solved... |
|
I use the following combination: python 3.6.5 Keep in mind, that cryptography has to be compiled against the new openssl version. Depending on your pip version you just might have reinstalled the cryptography binary. |
|
Hi, @mocart2 Are you solved it?, i have the same problem :( |
|
Me too.. |
|
This does not appear to be an OpenSSL issue. Please ask about this on a python forum. Closing. |
|
I'm not entirely sure it is "just a Python issue" since: Since the OP is an SBC user as well, but on orangepiplus2e, I assume it is a Debian flavour just like my armbian system. Are perhaps the Debian packages itself lacking X25519 support? Oddly enough keys can be created though: So since most people here want to likely use it for TLS key exchange (Firefox supports x25519 for this), I just want to ask if OpenSSL is broken on Debian as well, or why this curve cannot be accessed anywhere from within OpenSSL itself and Python's modules, once it comes to key exchange. Forgive me my thread necroing, I will not reply again unless you want me to, perhaps it is okay picking up on this issue. It cannot be just Python for the reasons above, or I made a mistake listing the supported curves. |
|
|
ECDH is what TLS servers use and what I need, so basically the correct use of listing confirmed?
Sorry but I never mentioned Curve25519 itself? Always referred solely to the need to use X25519.
The screenshot is just to illustrate the use on a server with nginx. However I need these in OpenSSL on a Debian based SBC, in particular in Python. Currently I only have secp384r1 which is also listed correctly in the I'm not forcing you into a discussion, but I feel like you misread my initial post. Why am I writing you this? Basically once you confirm me something is broken on Debian, I will contact the package maintainer. If this is an issue with me understanding something, please try to explain if you have a minute. PS: The previous creation of keys was merely an illustration. It's still all about X25519 for TLS. |
ECDH is a key agreement scheme used in the TLS protocol to agree secrets between a client and a server. X25519 is another key agreement scheme which is very similar to ECDH but slightly different - and can also be used in TLS. Sometimes people will use the term ECDH to refer to both things - but strictly speaking they are separate (different standards involved).
No - but you are looking at the output of Typically you don't need to worry about X25519 at all. You don't need to configure it, create keys for it, or parameters, or anything. These are created on-the-fly, and it will be offered by an OpenSSL client, and used by an OpenSSL server if offered by the client unless explicitly configured not to do so. All versions of OpenSSL that support TLSv1.3 also support X25519. For clients it is the default key agreement scheme in TLSv1.3.
What does this mean? How do you know you are only using this curve? |
There, I fixed my old posts? Sorry my exclusion angered you, but I really wanted to just skip the textbook basics and pretend to just get info on why these are inaccessible. Every attempt to get any reply why this [key agreement scheme] is excluded for me to select inside OpenSSL itself, rather than just Python was dodged by focusing on my petty wording. Yes yes I can run A+ SSL-Labs rated servers: Sorry for trying to have some fun and wanting to add extra support for a different [key agreement scheme] because NIST curves vs Curve25519 is a loaded issue which you prefer.
Because my servers run TLS1.2 and 1.3 to the highest recommended specs in industry standards? Instead of forcing me to brag, you should grant me the benefit of doubt that I'm no random git.
I try again:
|
|
Would |
I'm not angry - and I'm sorry if it came across that way. I'm simply trying to explain why X25519 doesn't appear in the output from
I'm not trying to force you to brag. Nor do I consider you a "random git". I'm trying to understand your context so I can provide better answers.
I'm not a python guy, and I'm not familiar with the python bindings - but my best guess (possibly wrong) is that this is a wrapper around our macro I wonder if there is a python wrapper for that function instead? |
|
One of the things that we're saying is that it available, but that
you're using a command that will never show X25519 because it's not
compatible with what that command does, and explain in details why
that's the case.
It could that that Python is overriding our defaults, and that
that it why you don't see it. If that's the case, I suggest you
talk to the Python people to either not override the default, or
have a better default.
Looking at an application written in Python, s_client also tells
me:
Server Temp Key: ECDH, P-256, 256 bits
While connecting to a different service on the same host, using
the same openssl version I get:
Server Temp Key: X25519, 253 bits
|
|
I suspect In the meantime X25519/X448 support has also been added (which is strictly speaking not ECDH and can't be controlled by the legacy Most applications don't need to worry about this stuff. They just get the default set of supported groups without calling anything specific (and that includes X25519). It's possible that python defaults to some specific ECDH curve using the old functions if you don't call |
|
UnsupportedAlgorithm: ed25519 is not supported by this version of OpenSSL doesn't work on OpenSSL 1.1.1f, cryptography-3.3.1, python 3.9 ubuntu 20.04, I tried manual install of openssl, edit ldconfig, move libraries, edit /etc/ld.so.conf.d/libc.conf, did't worked for me |
|
@nick2525 I would recommend opening a separate issue: they are not the same problem, as ed25519 is not a key exchange algorithm but just deals with signatures. In the new issue you might also want to include more details about what you are trying to do exactly when the error occurs. As a sidenote, it seems very likely that this is an issue in the python binding rather than in OpenSSL, so you might consider opening an issue in that project to receive the best support for your problem! |
|
Can you please try in Python3:
```
from cryptography.hazmat.backends import default_backend
default_backend().openssl_version_text()
```
25. 1. 2021 20:26, 20:26, nick2525 <notifications@github.com> napsal/a:
…UnsupportedAlgorithm: ed25519 is not supported by this version of
OpenSSL
doesn't work on OpenSSL 1.1.1f, cryptography-3.3.1, python 3.9 ubuntu
20.04, I tried manual install of openssl, edit ldconfig, move
libraries, edit /etc/ld.so.conf.d/libc.conf, did't worked for me
home-assistant/core#45363
#11227
postlund/pyatv#831
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#8837 (comment)
|
|
@t8m
|
|
remove python cache ./.cache/pip/wheels/ and reinstall cryptography fixes it |
Since v1.1.0, ECDH is always enabled with auto curve selection, and customizing curves is rarely needed or advisable. For v1.0.2, set auto-selection in server context construction. See openssl/openssl#8837 (comment)
i get latest version openssl:
wget --no-check-certificate https://www.openssl.org/source/openssl-1.1.1b.tar.gzunarchive it and configure:
./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlibthen:
make && make test && make installfixed links in os and cheked version:
and afterm i exec app (yowsup request):
i write about it yowsup developer, he says, upgrade openssl version 1.1.0+, i upgrade it, but it not works, may be i have mistake in configure proccess? can anybody help me please?
The text was updated successfully, but these errors were encountered: