-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
SSLContext.set_ecdh_curve() not accepting x25519 #77063
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Using SSLContext.set_ecdh_curve() it is neither possible to choose X25519, nor to choose a list of curves to be used for key agreement. |
This bug was originally the more generic issue bpo-32858. SSLContext.set_ecdh_curve() uses EC_KEY_new_by_curve_name() and SSL_CTX_set_tmp_ecdh() to configure the ECDH curve parameters. The current approach has multiple downsides. It doesn't work with X25519 and can only set one curve. OpenSSL 1.0.2+ has SSL_CTX_set1_curves_list(), which supports a list of curve names. Proposal: SSLContext.set_ecdh_curve() is changed from taking one curve name to an *arg of curve names. With OpenSSL 1.0.2+, 1..n curves are supported. For OpenSSL < 1.0.2 on 2.7-3.6, one curve is supported. Perhaps it makes sense to map an empty *arg to auto-configuration? I like to cover the issue in PEP-543, too. Cory, |
PEP-543 was withdrawn in the meantime. Any suggestion how to proceed with this? |
Any updates? |
|
GH-103378 partially fixed this: |
Is there interest in a PR which would add This would add the possibility to specify one or several curves (aka 'groups') by a colon separated string of curve names. As an alternative, one could change the existing code to avoid the somewhat cumbersome "string -> I'm fine either way, with a slight preference for the former: It introduces a new function, hence is guaranteed not to interfere with legacy code. But it's a new function which must be maintained going forward.... |
For the latter approach above, code would be replaced with this (tested on
Remark: This will also enable to use the OQS OpenSSL provider to achieve a 'quantum-hard' TLS key agreement, e.g. using |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: