crypto: support AES-*-SIV and AES-*-GCM-SIV in createCipheriv() #63393

What is the problem this feature will solve?

I would like Node.js node:crypto to expose AES-SIV and AES-GCM-SIV ciphers through crypto.getCiphers(), crypto.getCipherInfo(), crypto.createCipheriv() and crypto.createDecipheriv(), when the underlying OpenSSL version supports them.

OpenSSL documentation lists the following AES cipher names:

• AES-128-SIV
• AES-192-SIV
• AES-256-SIV
• AES-128-GCM-SIV
• AES-192-GCM-SIV
• AES-256-GCM-SIV

However, these do not appear to be available through Node.js node:crypto, even with a recent Node.js version backed by OpenSSL 3.5.x.

AES-GCM is widely available and useful, but it is very sensitive to nonce reuse. AES-SIV and AES-GCM-SIV are misuse-resistant authenticated encryption modes and are useful for application-level encryption APIs where accidental nonce reuse is a realistic operational risk.

In framework/library code, this would allow Node.js users to choose a safer AEAD mode where nonce misuse resistance is desirable.

Reproduction

const crypto = require('node:crypto');

console.log('Node.js version:', process.version);
console.log('OpenSSL version:', process.versions.openssl);
console.log('FIPS mode:', crypto.getFips());

const ciphers = crypto.getCiphers().sort();

console.log('SIV ciphers:', ciphers.filter((cipher) => cipher.includes('siv')));
console.log('GCM/SIV ciphers:', ciphers.filter((cipher) => cipher.includes('gcm') || cipher.includes('siv')));

for (const algorithm of [
  'aes-128-siv',
  'aes-192-siv',
  'aes-256-siv',
  'aes-128-gcm-siv',
  'aes-192-gcm-siv',
  'aes-256-gcm-siv',
]) {
  console.log(algorithm, crypto.getCipherInfo(algorithm));
}

On my machine:
Node.js version: v24.14.1
OpenSSL version: 3.5.5
FIPS mode: 0
SIV ciphers: []

crypto.getCiphers() does not include AES-SIV or AES-GCM-SIV algorithms.

If the underlying OpenSSL version supports these ciphers and the active provider allows them, I would expect Node.js to expose them through node:crypto, or at least document why they are intentionally unavailable.

This is not a FIPS-mode issue in my environment because crypto.getFips() returns 0. I understand that OpenSSL support does not automatically imply Node.js API exposure. I am opening this issue to ask whether exposing these ciphers is technically feasible and desirable in Node.js.

What is the feature you are proposing to solve the problem?

I propose that Node.js should expose AES-SIV and AES-GCM-SIV ciphers through node:crypto when they are available from the underlying OpenSSL build and active provider.

Ideally, this would include support for:

• crypto.getCiphers()
• crypto.getCipherInfo()
• crypto.createCipheriv()
• crypto.createDecipheriv()

for the following algorithms:

• aes-128-siv
• aes-192-siv
• aes-256-siv
• aes-128-gcm-siv
• aes-192-gcm-siv
• aes-256-gcm-siv

If these algorithms cannot safely fit into the current streaming Cipheriv / Decipheriv API because of their AEAD/SIV semantics, then I would like to propose one of the following alternatives:

1. Document explicitly why these OpenSSL-supported ciphers are not exposed through node:crypto.
2. Expose them through a non-streaming AEAD API in the future.
3. Provide a documented way to detect that the underlying OpenSSL version supports them, even if Node.js intentionally does not expose them.

The main goal is to make misuse-resistant authenticated encryption modes available to Node.js applications and libraries in a clear, supported, and documented way.

What alternatives have you considered?

I considered using the currently available aes-256-gcm cipher, which is supported by node:crypto today. This is a practical fallback, but it does not provide the same nonce-misuse resistance properties as AES-SIV or AES-GCM-SIV.

I also considered relying on a third-party cryptography library or native addon, but that adds supply-chain risk, maintenance overhead, and deployment complexity compared to using the built-in node:crypto module.

Another alternative would be to implement stricter nonce management at the application/framework level. This helps reduce the risk, but it does not fully replace a misuse-resistant AEAD mode.

Therefore, the preferred solution would be native, documented support in node:crypto, or at least clear documentation explaining why these OpenSSL-supported ciphers are not exposed.