.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.42)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
.    \" fudge factors for nroff and troff
.if n \{\
.    ds #H 0
.    ds #V .8m
.    ds #F .3m
.    ds #[ \f1
.    ds #] \fP
.\}
.if t \{\
.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
.    ds #V .6m
.    ds #F 0
.    ds #[ \&
.    ds #] \&
.\}
.    \" simple accents for nroff and troff
.if n \{\
.    ds ' \&
.    ds ` \&
.    ds ^ \&
.    ds , \&
.    ds ~ ~
.    ds /
.\}
.if t \{\
.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
.    \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
.    \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
.    \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
.    ds : e
.    ds 8 ss
.    ds o a
.    ds d- d\h'-1'\(ga
.    ds D- D\h'-1'\(hy
.    ds th \o'bp'
.    ds Th \o'LP'
.    ds ae ae
.    ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "SSL_CTX_SET1_CURVES 3ossl"
.TH SSL_CTX_SET1_CURVES 3ossl "2026-01-27" "3.5.5" "OpenSSL"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
SSL_CTX_set1_groups, SSL_CTX_set1_groups_list, SSL_set1_groups,
SSL_set1_groups_list, SSL_get1_groups, SSL_get0_iana_groups,
SSL_get_shared_group, SSL_get_negotiated_group, SSL_CTX_set1_curves,
SSL_CTX_set1_curves_list, SSL_set1_curves, SSL_set1_curves_list,
SSL_get1_curves, SSL_get_shared_curve, SSL_CTX_get0_implemented_groups
\&\- EC supported curve functions
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\& #include <openssl/ssl.h>
\&
\& int SSL_CTX_set1_groups(SSL_CTX *ctx, int *glist, int glistlen);
\& int SSL_CTX_set1_groups_list(SSL_CTX *ctx, char *list);
\&
\& int SSL_set1_groups(SSL *ssl, int *glist, int glistlen);
\& int SSL_set1_groups_list(SSL *ssl, char *list);
\&
\& int SSL_get1_groups(SSL *ssl, int *groups);
\& int SSL_get0_iana_groups(SSL *ssl, uint16_t **out);
\& int SSL_get_shared_group(SSL *s, int n);
\& int SSL_get_negotiated_group(SSL *s);
\&
\& int SSL_CTX_set1_curves(SSL_CTX *ctx, int *clist, int clistlen);
\& int SSL_CTX_set1_curves_list(SSL_CTX *ctx, char *list);
\&
\& int SSL_set1_curves(SSL *ssl, int *clist, int clistlen);
\& int SSL_set1_curves_list(SSL *ssl, char *list);
\&
\& int SSL_get1_curves(SSL *ssl, int *curves);
\& int SSL_get_shared_curve(SSL *s, int n);
\&
\& int SSL_CTX_get0_implemented_groups(SSL_CTX *ctx, int all,
\&                                     STACK_OF(OPENSSL_CSTRING) *names);
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
For all of the functions below that set the supported groups there must be at
least one group in the list. A number of these functions identify groups via a
unique integer \s-1NID\s0 value. However, support for some groups may be added by
external providers. In this case there will be no \s-1NID\s0 assigned for the group.
When setting such groups applications should use the \*(L"list\*(R" form of these
functions (i.e. \fBSSL_CTX_set1_groups_list()\fR and \fBSSL_set1_groups_list()\fR).
.PP
\&\fBSSL_CTX_set1_groups()\fR sets the supported groups for \fBctx\fR to \fBglistlen\fR
groups in the array \fBglist\fR. The array consist of all NIDs of supported groups.
The supported groups for \fBTLSv1.3\fR include:
\&\fBNID_X9_62_prime256v1\fR,
\&\fBNID_secp384r1\fR,
\&\fBNID_secp521r1\fR,
\&\fB\s-1NID_X25519\s0\fR,
\&\fB\s-1NID_X448\s0\fR,
\&\fBNID_brainpoolP256r1tls13\fR,
\&\fBNID_brainpoolP384r1tls13\fR,
\&\fBNID_brainpoolP512r1tls13\fR,
\&\fBNID_ffdhe2048\fR,
\&\fBNID_ffdhe3072\fR,
\&\fBNID_ffdhe4096\fR,
\&\fBNID_ffdhe6144\fR, and
\&\fBNID_ffdhe8192\fR.
OpenSSL will use this array in different ways based on the \s-1TLS\s0 version, and
whether the groups are used in a client or server.
.PP
For a \s-1TLS\s0 client, the groups are used directly in the supported groups
extension. The extension's preference order, to be evaluated by the server, is
determined by the order of the elements in the array.
.PP
For a \s-1TLS 1.2\s0 server, the groups determine the selected group. If
\&\fB\s-1SSL_OP_CIPHER_SERVER_PREFERENCE\s0\fR is set, the order of the elements in the
array determines the selected group. Otherwise, the order is ignored and the
client's order determines the selection.
.PP
For a \s-1TLS 1.3\s0 server, the groups determine the selected group, but
selection is more complex. A \s-1TLS 1.3\s0 client sends both a group list as well as a
predicted subset of groups. Choosing a group outside the predicted subset incurs
an extra roundtrip. However, in some situations, the most preferred group may
not be predicted. OpenSSL considers all supported groups in \fIclist\fR to be comparable
in security and prioritizes avoiding roundtrips above either client or server
preference order. If an application uses an external provider to extend OpenSSL
with, e.g., a post-quantum algorithm, this behavior may allow a network attacker
to downgrade connections to a weaker algorithm. It is therefore recommended
to use \fBSSL_CTX_set1_groups_list()\fR with the ability to specify group tuples.
.PP
\&\fBSSL_CTX_set1_groups_list()\fR sets the supported groups for \fBctx\fR to
string \fIlist\fR. In contrast to \fBSSL_CTX_set1_groups()\fR, the names of the
groups, rather than their NIDs, are used.
.PP
The commands below list the available groups for \s-1TLS 1.2\s0 and \s-1TLS 1.3,\s0
respectively:
.PP
.Vb 2
\&    $ openssl list \-tls1_2 \-tls\-groups
\&    $ openssl list \-tls1_3 \-tls\-groups
.Ve
.PP
Each group can be either the \fB\s-1NIST\s0\fR name (e.g. \fBP\-256\fR), some other commonly
used name where applicable (e.g. \fBX25519\fR, \fBffdhe2048\fR) or an OpenSSL \s-1OID\s0 name
(e.g. \fBprime256v1\fR).
Group names are case-insensitive in OpenSSL 3.5 and later.
The preferred group names are those defined by
\&\s-1IANA\s0 <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8>.
.PP
The \fIlist\fR can be used to define several group tuples of comparable security
levels, and can specify which key shares should be sent by a client.
The specified list elements can optionally be ignored, if not implemented
(listing unknown groups otherwise results in error).
It is also possible to specify the built-in default set of groups, and to explicitly
remove a group from that list.
.PP
In its simplest form, the string \fIlist\fR is just a colon separated list
of group names, for example \*(L"P\-521:P\-384:P\-256:X25519:ffdhe2048\*(R". The first
group listed will also be used for the \fBkey_share\fR sent by a client in a
TLSv1.3 \fBClientHello\fR. For servers note the discussion above. The list should
be in order of preference with the most preferred group first.
.PP
Group tuples of comparable security are defined by separating them from each
other by a tuple separator \f(CW\*(C`/\*(C'\fR. Keyshares to be sent by a client are specified
by prepending a \f(CW\*(C`*\*(C'\fR to the group name, while any \f(CW\*(C`*\*(C'\fR will be ignored by a
server. The following string \fIlist\fR for example defines three tuples when
used on the server-side, and triggers the generation of three key shares
when used on the client-side: P\-521:*P\-256/*P\-384/*X25519:P\-384:ffdhe2048.
.PP
If a group name is preceded with the \f(CW\*(C`?\*(C'\fR character, it will be ignored if an
implementation is missing. If a group name is preceded with the \f(CW\*(C`\-\*(C'\fR character, it
will be removed from the list of groups if present (including not sending a
key share for this group), ignored otherwise. The pseudo group name
\&\f(CW\*(C`DEFAULT\*(C'\fR can be used to select the OpenSSL built-in default list of groups.
.PP
For a \s-1TLS 1.3\s0 client, all the groups in the string \fIlist\fR are added to the
supported groups extension of a \f(CW\*(C`ClientHello\*(C'\fR, in the order in which they are listed,
thereby interpreting tuple separators as group separators. The extension's
preference order, to be evaluated by the server, is determined by the
order of the elements in the array, see below.
.PP
If a group name is preceded by \f(CW\*(C`*\*(C'\fR, a key share will be sent for this group.
When preceding \f(CW\*(C`DEFAULT\*(C'\fR with \f(CW\*(C`*\*(C'\fR, a key share will be sent for the first group
of the OpenSSL built-in default list of groups. If no \f(CW\*(C`*\*(C'\fR is used anywhere in the list,
a single key share for the leftmost valid group is sent. A maximum of 4 key shares
are supported. Example: \*(L"P\-521:*P\-256/*P\-384\*(R" will add P\-521, P\-256 and P\-384 to the
supported groups extension in a \f(CW\*(C`ClientHello\*(C'\fR and will send key shares for P\-256 and P\-384.
.PP
For a \s-1TLS 1.3\s0 server, the groups in the string \fIlist\fR will be used to determine which group
is used for the key agreement. The preference order of the group tuples is determined
by the order of the tuples in the array, and the preference order of the groups within
a group tuple is determined by the order of the groups in the tuple. Server preference
can be enforced by setting \fB\s-1SSL_OP_CIPHER_SERVER_PREFERENCE\s0\fR using
\&\fBSSL_set_options\fR (default: client preference).
.PP
The server will select the group to be used for a key agreement using the following
pseudo-code algorithm:
.PP
.Vb 12
\& FOR each group tuple
\&     IF client preference (= default)
\&         FOR each client key\-share group
\&             IF current key\-share group is also part of current group tuple: SH, return success
\&         FOR each client supported groups
\&             IF current supported group is also part of current group tuple: HRR, return success
\&     ELSE (= server preference = with SSL_OP_CIPHER_SERVER_PREFERENCE option set)
\&         FOR each group in current tuple
\&             IF current group is also part of client key\-share groups: SH, return success
\&         FOR each group in current tuple
\&             IF current group is also part of client supported groups: HRR, return success
\& return failure
\&
\& with : SH:  Server hello with current group
\&        HRR: Server retry request with current group
.Ve
.PP
Hence, if a client supports a group in a server group tuple, but does not send a key
share for this group, a Hello Retry Request (\s-1HRR\s0) is triggered, asking the client
to send a new Hello message with a more preferred keyshare. See examples below.
.PP
A group name can optionally be preceded by any of \f(CW\*(C`*\*(C'\fR, \f(CW\*(C`?\*(C'\fR or \f(CW\*(C`\-\*(C'\fR, in any order, with
the exception that only \f(CW\*(C`*\*(C'\fR is allowed to precede \f(CW\*(C`DEFAULT\*(C'\fR. Separator characters
\&\f(CW\*(C`:\*(C'\fR and \f(CW\*(C`/\*(C'\fR are only allowed inside the \fIlist\fR and not at the very beginning or end.
.PP
\&\fBSSL_set1_groups()\fR and \fBSSL_set1_groups_list()\fR are similar except they set
supported groups for the \s-1SSL\s0 structure \fBssl\fR.
.PP
\&\fBSSL_get1_groups()\fR returns the set of supported groups sent by a client
in the supported groups extension. It returns the total number of
supported groups. The \fBgroups\fR parameter can be \fB\s-1NULL\s0\fR to simply
return the number of groups for memory allocation purposes. The
\&\fBgroups\fR array is in the form of a set of group NIDs in preference
order. It can return zero if the client did not send a supported groups
extension. If a supported group \s-1NID\s0 is unknown then the value is set to the
bitwise \s-1OR\s0 of TLSEXT_nid_unknown (0x1000000) and the id of the group.
.PP
\&\fBSSL_get0_iana_groups()\fR retrieves the list of groups sent by the
client in the supported_groups extension.  The \fB*out\fR array of bytes
is populated with the host-byte-order representation of the uint16_t group
identifiers, as assigned by \s-1IANA.\s0  The group list is returned in the same order
that was received in the ClientHello.  The return value is the number of groups,
not the number of bytes written.
.PP
\&\fBSSL_get_shared_group()\fR returns the \s-1NID\s0 of the shared group \fBn\fR for a
server-side \s-1SSL\s0 \fBssl\fR. If \fBn\fR is \-1 then the total number of shared groups is
returned, which may be zero. Other than for diagnostic purposes,
most applications will only be interested in the first shared group
so \fBn\fR is normally set to zero. If the value \fBn\fR is out of range,
NID_undef is returned. If the \s-1NID\s0 for the shared group is unknown then the value
is set to the bitwise \s-1OR\s0 of TLSEXT_nid_unknown (0x1000000) and the id of the
group.
.PP
\&\fBSSL_get_negotiated_group()\fR returns the \s-1NID\s0 of the negotiated group used for
the handshake key exchange process.  For TLSv1.3 connections this typically
reflects the state of the current connection, though in the case of PSK-only
resumption, the returned value will be from a previous connection.  For earlier
\&\s-1TLS\s0 versions, when a session has been resumed, it always reflects the group
used for key exchange during the initial handshake (otherwise it is from the
current, non-resumption, connection).  This can be called by either client or
server. If the \s-1NID\s0 for the shared group is unknown then the value is set to the
bitwise \s-1OR\s0 of TLSEXT_nid_unknown (0x1000000) and the id of the group. See also
\&\fBSSL_get0_group_name\fR\|(3) which returns the name of the negotiated group
directly and is generally preferred over \fBSSL_get_negotiated_group()\fR.
.PP
\&\fBSSL_CTX_get0_implemented_groups()\fR populates a stack with the names of \s-1TLS\s0
groups that are compatible with the \s-1TLS\s0 version of the \fBctx\fR argument.
The returned names are references to internal constants and must not be
modified or freed.  When \fBall\fR is nonzero, the returned list includes not
only the preferred \s-1IANA\s0 names of the groups, but also any associated aliases.
If the \s-1SSL_CTX\s0 is version-flexible, the groups will be those compatible
with any configured minimum and maximum protocol versions.
The \fBnames\fR stack should be allocated by the caller and be empty, the
matching group names are appended to the provided stack.
The \fB\-tls\-groups\fR and \fB\-all\-tls\-groups\fR options of the
openssl list command output these lists for either
\&\s-1TLS 1.2\s0 or \s-1TLS 1.3\s0 (by default).
.PP
All these functions are implemented as macros.
.PP
The curve functions are synonyms for the equivalently named group functions and
are identical in every respect. They exist because, prior to \s-1TLS1.3,\s0 there was
only the concept of supported curves. In \s-1TLS1.3\s0 this was renamed to supported
groups, and extended to include Diffie Hellman groups. The group functions
should be used in preference.
.SH "NOTES"
.IX Header "NOTES"
If an application wishes to make use of several of these functions for
configuration purposes either on a command line or in a file it should
consider using the \s-1SSL_CONF\s0 interface instead of manually parsing options.
.SH "RETURN VALUES"
.IX Header "RETURN VALUES"
\&\fBSSL_CTX_set1_groups()\fR, \fBSSL_CTX_set1_groups_list()\fR, \fBSSL_set1_groups()\fR,
\&\fBSSL_set1_groups_list()\fR, and \fBSSL_CTX_get0_implemented_groups()\fR return 1 for
success and 0 for failure.
.PP
\&\fBSSL_get1_groups()\fR returns the number of groups, which may be zero.
.PP
\&\fBSSL_get0_iana_groups()\fR returns the number of (uint16_t) groups, which may be zero.
.PP
\&\fBSSL_get_shared_group()\fR returns the \s-1NID\s0 of shared group \fBn\fR or NID_undef if there
is no shared group \fBn\fR; or the total number of shared groups if \fBn\fR
is \-1.
.PP
When called on a client \fBssl\fR, \fBSSL_get_shared_group()\fR has no meaning and
returns \-1.
.PP
\&\fBSSL_get_negotiated_group()\fR returns the \s-1NID\s0 of the negotiated group used for
key exchange, or NID_undef if there was no negotiated group.
.SH "EXAMPLES"
.IX Header "EXAMPLES"
Assume the server \fIlist\fR is \*(L"P\-521:P\-256/P\-384/X25519:ffdhe2048\*(R" and client
\&\fIlist\fR is \*(L"P\-521:*P\-384\*(R" when connecting to such a server, meaning that the
client supports \f(CW\*(C`P\-521\*(C'\fR but does not send a key share for this group to the
server, and the client supports \f(CW\*(C`P\-384\*(C'\fR including key share for this group.
With both server and client preference, an \s-1HRR\s0 will be triggered for \f(CW\*(C`P\-521\*(C'\fR
despite the availability of a key share for P\-384, which overlaps with a lower
priority server-side tuple.
.PP
As a separate example, consider a server \fIlist\fR \*(L"A:B/C:D/E:F\*(R". Listed in order
of highest preference to least, 3 group tuples are created: \*(L"A:B\*(R", \*(L"C:D\*(R", and
\&\*(L"E:F\*(R". Here are some examples of a client \fIlist\fR where setting server/client
preference will not change the outcome:
.PP
\&\- \*(L"A:D:*F\*(R": Both prefer \*(L"A\*(R", but the server didn't receive a keyshare for the
most-preferred tuple in which there's at least one group supported by both.
Therefore, an \s-1HRR\s0 is triggered for \*(L"A\*(R".
.PP
\&\- \*(L"B:*C\*(R": Both prefer \*(L"B\*(R" from the first group tuple \*(L"A:B\*(R", so an \s-1HRR\s0 is
triggered for \*(L"B\*(R".
.PP
\&\- \*(L"C:*F\*(R": Both prefer \*(L"C\*(R" from the second group tuple \*(L"C:D\*(R", so an \s-1HRR\s0 is
triggered for \*(L"C\*(R".
.PP
\&\- \*(L"C:*D\*(R": Even though both prefer \*(L"C\*(R" over \*(L"D\*(R", the server will accept
the key share for \*(L"D\*(R". Within a tuple, existing keyshares trump preference
order.
.PP
\&\- \*(L"*C:*D\*(R": The server accepts the \*(L"C\*(R" key share.
.PP
\&\- \*(L"F\*(R": Even though it is not prepended with a \*(L"*\*(R", the client will send a key
share for \*(L"F\*(R". The server will then accept the key share for \*(L"F\*(R".
.PP
\&\- \*(L"*E:C:A\*(R": The server prefers \*(L"A\*(R" from the \*(L"A:B\*(R" group tuple, so an \s-1HRR\s0 is
triggered for \*(L"A\*(R".
.PP
\&\- \*(L"*E:B:*A\*(R": The server uses the key share for \*(L"A\*(R".
.PP
Here are some examples where setting server/client preference will change the
result:
.PP
\&\- \*(L"*D:*C\*(R"
  \- Client preference: The server uses the key share for \*(L"D\*(R".
  \- Server preference: The server uses the key share for \*(L"C\*(R".
.PP
\&\- \*(L"B:A:*C\*(R"
  \- Client preference: The server triggers an \s-1HRR\s0 for \*(L"B\*(R". For the server,
\&\*(L"A\*(R" and \*(L"B\*(R" are considered comparable in security. But because the client
prefers \*(L"B\*(R", the server will trigger an \s-1HRR\s0 for \*(L"B\*(R".
  \- Server preference: The server triggers an \s-1HRR\s0 for \*(L"A\*(R".
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fBssl\fR\|(7),
\&\fBSSL_CTX_add_extra_chain_cert\fR\|(3),
\&\fBSSL_get0_group_name\fR\|(3)
.SH "HISTORY"
.IX Header "HISTORY"
The curve functions were added in OpenSSL 1.0.2. The equivalent group
functions were added in OpenSSL 1.1.1. The \fBSSL_get_negotiated_group()\fR function
was added in OpenSSL 3.0.0.
.PP
Support for ignoring unknown groups in \fBSSL_CTX_set1_groups_list()\fR and
\&\fBSSL_set1_groups_list()\fR was added in OpenSSL 3.3.
.PP
Support for \fBML-KEM\fR was added in OpenSSL 3.5.
.PP
OpenSSL 3.5 also introduces support for three \fIhybrid\fR \s-1ECDH PQ\s0 key exchange
\&\s-1TLS\s0 groups: \fBX25519MLKEM768\fR, \fBSecP256r1MLKEM768\fR and
\&\fBSecP384r1MLKEM1024\fR.
They offer \s-1CPU\s0 performance comparable to the associated \s-1ECDH\s0 group, though at
the cost of significantly larger key exchange messages.
The third group, \fBSecP384r1MLKEM1024\fR is substantially more CPU-intensive,
largely as a result of the high \s-1CPU\s0 cost of \s-1ECDH\s0 for the underlying \fBP\-384\fR
group.
Also its key exchange messages at close to 1700 bytes are larger than the
roughly 1200 bytes for the first two groups.
.PP
As of OpenSSL 3.5 key exchange group names are case-insensitive.
.PP
\&\fBSSL_CTX_get0_implemented_groups\fR was first implemented in OpenSSL 3.5.
.PP
Earlier versions of this document described the list as a preference order.
However, OpenSSL's behavior as a \s-1TLS 1.3\s0 server is to consider \fIall\fR
supported groups as comparable in security.
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright 2013\-2025 The OpenSSL Project Authors. All Rights Reserved.
.PP
Licensed under the Apache License 2.0 (the \*(L"License\*(R").  You may not use
this file except in compliance with the License.  You can obtain a copy
in the file \s-1LICENSE\s0 in the source distribution or at
<https://www.openssl.org/source/license.html>.
