Lines Matching full:group
42 least one group in the list. A number of these functions identify groups via a
44 external providers. In this case there will be no NID assigned for the group.
71 For a TLS 1.2 server, the groups determine the selected group. If
73 array determines the selected group. Otherwise, the order is ignored and the
76 For a TLS 1.3 server, the groups determine the selected group, but
77 selection is more complex. A TLS 1.3 client sends both a group list as well as a
78 predicted subset of groups. Choosing a group outside the predicted subset incurs
79 an extra roundtrip. However, in some situations, the most preferred group may
85 to use SSL_CTX_set1_groups_list() with the ability to specify group tuples.
97 Each group can be either the B<NIST> name (e.g. B<P-256>), some other commonly
100 Group names are case-insensitive in OpenSSL 3.5 and later.
101 The preferred group names are those defined by
104 The I<list> can be used to define several group tuples of comparable security
109 remove a group from that list.
112 of group names, for example "P-521:P-384:P-256:X25519:ffdhe2048". The first
113 group listed will also be used for the B<key_share> sent by a client in a
115 be in order of preference with the most preferred group first.
117 Group tuples of comparable security are defined by separating them from each
119 by prepending a C<*> to the group name, while any C<*> will be ignored by a
124 If a group name is preceded with the C<?> character, it will be ignored if an
125 implementation is missing. If a group name is preceded with the C<-> character, it
127 key share for this group), ignored otherwise. The pseudo group name
132 thereby interpreting tuple separators as group separators. The extension's
136 If a group name is preceded by C<*>, a key share will be sent for this group.
137 When preceding C<DEFAULT> with C<*>, a key share will be sent for the first group
139 a single key share for the leftmost valid group is sent. A maximum of 4 key shares
143 For a TLS 1.3 server, the groups in the string I<list> will be used to determine which group
144 is used for the key agreement. The preference order of the group tuples is determined
146 a group tuple is determined by the order of the groups in the tuple. Server preference
150 The server will select the group to be used for a key agreement using the following
153 FOR each group tuple
155 FOR each client key-share group
156 IF current key-share group is also part of current group tuple: SH, return success
158 IF current supported group is also part of current group tuple: HRR, return success
160 FOR each group in current tuple
161 IF current group is also part of client key-share groups: SH, return success
162 FOR each group in current tuple
163 IF current group is also part of client supported groups: HRR, return success
166 with : SH: Server hello with current group
167 HRR: Server retry request with current group
169 Hence, if a client supports a group in a server group tuple, but does not send a key
170 share for this group, a Hello Retry Request (HRR) is triggered, asking the client
173 A group name can optionally be preceded by any of C<*>, C<?> or C<->, in any order, with
184 B<groups> array is in the form of a set of group NIDs in preference
186 extension. If a supported group NID is unknown then the value is set to the
187 bitwise OR of TLSEXT_nid_unknown (0x1000000) and the id of the group.
191 is populated with the host-byte-order representation of the uint16_t group
192 identifiers, as assigned by IANA. The group list is returned in the same order
196 SSL_get_shared_group() returns the NID of the shared group B<n> for a
199 most applications will only be interested in the first shared group
201 NID_undef is returned. If the NID for the shared group is unknown then the value
203 group.
205 SSL_get_negotiated_group() returns the NID of the negotiated group used for
209 TLS versions, when a session has been resumed, it always reflects the group
212 server. If the NID for the shared group is unknown then the value is set to the
213 bitwise OR of TLSEXT_nid_unknown (0x1000000) and the id of the group. See also
214 L<SSL_get0_group_name(3)> which returns the name of the negotiated group
225 matching group names are appended to the provided stack.
232 The curve functions are synonyms for the equivalently named group functions and
235 groups, and extended to include Diffie Hellman groups. The group functions
254 SSL_get_shared_group() returns the NID of shared group B<n> or NID_undef if there
255 is no shared group B<n>; or the total number of shared groups if B<n>
261 SSL_get_negotiated_group() returns the NID of the negotiated group used for
262 key exchange, or NID_undef if there was no negotiated group.
268 client supports C<P-521> but does not send a key share for this group to the
269 server, and the client supports C<P-384> including key share for this group.
275 of highest preference to least, 3 group tuples are created: "A:B", "C:D", and
280 most-preferred tuple in which there's at least one group supported by both.
283 - "B:*C": Both prefer "B" from the first group tuple "A:B", so an HRR is
286 - "C:*F": Both prefer "C" from the second group tuple "C:D", so an HRR is
298 - "*E:C:A": The server prefers "A" from the "A:B" group tuple, so an HRR is
324 The curve functions were added in OpenSSL 1.0.2. The equivalent group
336 They offer CPU performance comparable to the associated ECDH group, though at
338 The third group, B<SecP384r1MLKEM1024> is substantially more CPU-intensive,
340 group.
344 As of OpenSSL 3.5 key exchange group names are case-insensitive.