Join Log in
Score:0
randomname avatar Crypto

How can I dentify the ECDHE group value used in a TLS session

us flag
randomname

In ECDHE, the group is a public value. I want to get this value for a session. I inspected the session using Wireshark. Under the ServerHello -> Key share extension -> Key share entry, I found these parameters:

Key Share Entry: Group: x25519, Key Exchange length: 32
Group: x25519 (29)
Key Exchange Length: 32
Key Exchange: 22d9....88e....635... (full length is 64 hex character, 256 bit)

Can you explain more? How can the Key Exchange Length value is 32 then, but it is 256 bit and 64 hex char?

100
0 + 0
tls
kelalaka avatar
in flag
kelalaka
It is 32 bytes and that is 64 hex char. Tool-related questions are off-topic here.
1
Reply
randomname avatar
us flag
randomname
@kelalaka Thank you! The post is not about the tool. But which value is it from the posted tool output?
0
Reply
kelalaka avatar
in flag
kelalaka
@knaccc this is ECC notation; it should be $x([a]G)$. It is $x22519(a,9)$ in the RFC notation that executes Montgomery Ladder and returns only the first coordinate. I'm not sure how Wireshark really sees this, however, it seems that they skip the base point encoding. See [rfc7748 6.1](https://datatracker.ietf.org/doc/html/rfc7748#section-6.1) and section 5. Do you think that this question is really answerable? TLS 1.3 says that obey rfc7748 where the encoding of $9$ is also 32-byte.
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
Yeah, the public key is always compressed for this x25519 in raw format (just a statically sized big endian integer). The size of that is 256 bit (crypto notation), 32 bytes (in the protocol) or - for human consumption only - 64 hex characters.
1
Reply
Score:2
knaccc avatar Crypto
es flag
knaccc

The TLS 1.3 handshake works as follows:

The client will send a "ClientHello" data structure to the server. At this stage, the client does not yet know which "Groups" the server supports. To avoid an extra round-trip to the server, it can speculatively contain a "group element" for the group it would prefer to use. In the case asked about, the group element is a 32-byte public key for use with "Group 29" (29 == hex 0x1d), which is a TLS identifier for what is commonly known as X25519. A list of the numbering for all TLS supported groups is here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

X25519 means a Diffie-Hellman exchange using a well-known base point G on the Curve25519 elliptic curve, where group elements are in the large cyclic subgroup containing G within this curve. The point G does not have to be transmitted, because it's defined as part of the X25519 standard and is the same for all invocations of X25519.

The client's ephemeral public key is the "group element" which was speculatively sent. For X25519, it is 32 bytes long (64 hex characters, or 256 bits). This group element is listed as the "key exchange" value in the "key share" section of the ClientHello data structure.

The server will respond with a "ServerHello" message if it agrees to use the client's speculatively-included group, here Group 29. This includes the server's group element in the "key exchange" value in the "key share" section. This group element is the server's ephemeral public key.

With this information, both the client and server will be able to each calculate the same shared secret called the "pre-master secret". This is then combined with the ClientHello and ServerHello data to derive symmetric encryption keys (see https://datatracker.ietf.org/doc/html/rfc8446#section-7.1). These allow the server and client to securely communicate with one another using authenticated encryption such as AES-GCM.

If the server doesn't agree to the client's proposed group, or the client opted not to propose any group, but the server does agree to an(other) group the client listed in "supported groups", it instead sends HelloRetryRequest which tells the client to retry the ClientHello using a specified group, which the server then accepts as above. If the server doesn't agree to any group the client supports, it sends an error alert and the handshake fails -- unless the client also proposed an available PSK, but usually that only happens for resumption, and if the initial handshake fails resumption is not possible.

TLS 1.0-1.2 handle ECDHE differently -- if at all, because there it is optional. In those protocols the ciphersuite specifies key-exchange and authentication as well as the data cipher and hash for HMAC (if not AEAD) and PRF (if 1.2). The client sends ClientHello listing ciphersuites it supports, any, some, or all of which may use ECDHE in combination with either RSA or ECDSA authentication (i.e. certificate), and a supported-groups extension (or supported-curves before RFC7919) specifying the curves it supports. If the server agrees to an offered ECDHE ciphersuite and an offered curve, it sends ServerHello specifying the ciphersuite, then its certificate chain, then ServerKeyExchange containing the curve id and its ephemeral public key. The client (if it accepts the certificate) sends ClientKeyExchange containing its ephemeral public key, after which the shared-secret computation proceeds similarly, although the details of how the working keys are derived differ from 1.3 and also between 1.2 and earlier.

0 + 0
kelalaka avatar
in flag
kelalaka
this is ECC notation; it should be $x([a]G)$. It is $x22519(a,9)$ in the RFC notation that executes Montgomery Ladder and returns only the first coordinate. I'm not sure how Wireshark really sees this, however, it seems that they skip the base point encoding. See [rfc7748 6.1](https://datatracker.ietf.org/doc/html/rfc7748#section-6.1) and section 5. Do you think that this question is really answerable? TLS 1.3 says that obey rfc7748 where the encoding of $9$ is also 32-byte.
0
Reply
knaccc avatar
es flag
knaccc
@kelalaka the "key exchange" hex in ServerHello is the server's public key, which is the base point (x coordinate of 9) scalar multiplied with the server's private key, or X25519(server_private_key, 9) in the rfc7748 notation. Not sure what you mean by "skip the base point encoding" - there is never a need to transmit the base point 9, since it's well-known as part of the X25519 spec.
0
Reply
kelalaka avatar
in flag
kelalaka
As I said simply under the question is about mapping the standard into WireShark that gives no information about the encoded basepoint $9$. Why they showed like this is upto the designer's choice.
0
Reply
knaccc avatar
es flag
knaccc
@kelalaka I think we interpreted the question differently. I assumed the problem was that the poster was confused about what "group" meant, especially since group could mean "group 29", could mean the group element that is the server's public key, or could mean the group of the base point. Therefore my approach was to just explain all the terminology.
0
Reply
Score:0
DannyNiu avatar Crypto
vu flag
DannyNiu

The group is that used in X25519 key exchange, which uses DJB's (Daniel J. Bernstein) Curve25519.

There is a series of commercial standards known as SEC#* (Standard for Efficient Cryptography) specifying elliptic-curve cryptography. Public keys (points) in these standards are either 2x+1 (uncompressed x-y coordinates with a header byte) or x+1 (compressed x coordinate with a header byte) bytes long.

There's also DJB and his teams effort on creating efficient and side-channel-free curves now known as X25519 (for key exchange) and Ed25519 (for digital signature). The public keys are also points, but they are defined directly in terms of the byte encoding of a coordinate in 1 dimension, thus there's no need for a header byte.

Your tool indicated that it's x25519, which is created by DJB folks.

You may also be interested to know that, there's another series of standards known as PKCS#* (Public-Key Cryptography Standard), the 1st in the series specified the RSA cryptography used in the internet, (there are other RSA standards used elsewhere).

0 + 0
kelalaka avatar
in flag
kelalaka
X25519 doesn't use $y$ coordinate.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.