tlsSocket.getEphemeralKeyInfo() - doesn't display information for hybrid groups

[tjuhaszrh]

Version

22.16.0

Platform

Linux x 6.12.0-116.el10.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug  1 19:40:37 EDT 2025 x86_64 GNU/Linux

Subsystem

TLS

What steps will reproduce the bug?

By creating a simple client and server script.

Code for server.js:

const tls = require("tls");
const fs = require("fs");

const options = {
  key: fs.readFileSync("key.pem"),
  cert: fs.readFileSync("cert.pem"),
  maxVersion: "TLSv1.3",
  ciphers: "", 
  ecdhCurve: "SecP384r1MLKEM1024",
};

const server = tls.createServer(options, (socket) => {
});

server.listen(8000, () => {
});

Code for client.js:

const tls = require("tls");
const fs = require("fs");

const options = {
  ca: fs.readFileSync("cert.pem"),
  rejectUnauthorized: true,
  servername: "localhost",
  maxVersion: "TLSv1.3",
  ciphers: "",
  ecdhCurve: "X25519:secp256r1:SecP384r1MLKEM1024",
};

const client = tls.connect(8000, "localhost", options, () => {
  const ephemeralKeyInfo = client.getEphemeralKeyInfo();
  console.log("Client - Ephemeral Key Info:", ephemeralKeyInfo);
});

client.on("data", (data) => {
  client.end();
});

client.on("close", () => {
});

Commands used for generating key/cert:

openssl genpkey -algorithm ML-DSA-44 -out key.pem
openssl req -x509 -new -key key.pem -out cert.pem -nodes -days 365 -subj "/CN=localhost"

and then starting the server and connecting with the client:

node server.js & 
node client.js

How often does it reproduce? Is there a required condition?

Always, when following reproduction steps.

What is the expected behavior? Why is that the expected behavior?

The standard output of getEphemeralKeyInfo() as is for non-hybrid groups.

For example if this would be the ecdhCurve option specified in the server.js:

ecdhCurve: 'X25519'

which returns this result:

[root@kvm-08-guest21 ~]# node client.js 
Client - Ephemeral Key Info: { type: 'ECDH', name: 'X25519', size: 253 }

So for a hybrid-key something like this:
Client - Ephemeral Key Info: { type: 'Hybrid', name: 'SecP384r1MLKEM1024', size: <combined-size> }

What do you see instead?

An empty object is returned.

[root@kvm-08-guest21 ~]# node client.js 
Client - Ephemeral Key Info: {}

Additional information

I have been recently trying to verify the usage of hybrid-groups in nodejs component. Trying to verify used groups I couldn't access the information through TLS module itself and had to use openssl client.

I'm testing this on distribution in which nodejs is build with the --shared-openssl configuration.

Systems openssl:

openssl -v
OpenSSL 3.5.1 1 Jul 2025 (Library: OpenSSL 3.5.1 1 Jul 2025)

[richardlau]

cc @nodejs/crypto

[panva]

https://nodejs.org/docs/latest-v22.x/api/tls.html#tlssocketgetephemeralkeyinfo

The supported types are 'DH' and 'ECDH'.

The project has only sat on OpenSSL 3.5.x for a couple weeks. This API has not been adapted for PQ/T hybrids nor full-on PQ.

This isn't a bug, it behaves as documented but is surely something to look into now that OpenSSL 3.5 is on main.

[mag123c]

I'd like to work on this issue.

From my analysis, the issue is that GetEphemeralKey() in src/crypto/crypto_common.cc doesn't handle the new hybrid post-quantum key types introduced in OpenSSL 3.5.x.

Approach:

• Add a default case in the switch statement to handle unknown key types (including hybrid keys)
• Use OBJ_nid2sn() to get the key type name dynamically
• Return format: { type: 'Hybrid', name: 'X25519MLKEM768', size: <key_size> }
• Add test placeholders for OpenSSL 3.5+ hybrid key scenarios

Does this approach sound reasonable? I'll start working on a PR if this looks good to you.

[github-actions]

This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[github-actions]

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.