PR-URL: https://github.com/nodejs/node/pull/53784
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
OpenSSL 3 deprecated support for custom engines with a recommendation
to switch to its new provider model.
PR-URL: https://github.com/nodejs/node/pull/53329
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This introduces a runtime deprecation for using GCM authentication tags
that are shorter than the cipher's block size, unless the user
specified the authTagLength option. This behavior has been doc-only
deprecated since 8f61b658de.
Refs: https://github.com/nodejs/node/issues/52327
Refs: https://github.com/nodejs/node/pull/52345
PR-URL: https://github.com/nodejs/node/pull/52552
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This introduces a doc-only deprecation of using GCM authentication tags
that are shorter than the cipher's block size, unless the user specified
the authTagLength option.
Refs: https://github.com/nodejs/node/issues/52327
PR-URL: https://github.com/nodejs/node/pull/52345
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/52069
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/51978
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This patch introduces a helper crypto.hash() that computes
a digest from the input at one shot. This can be 1.2-1.6x faster
than the object-based createHash() for smaller inputs (<= 5MB)
that are readily available (not streamed) and incur less memory
overhead since no intermediate objects will be created.
PR-URL: https://github.com/nodejs/node/pull/51044
Refs: https://github.com/nodejs/performance/issues/136
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
PR-URL: https://github.com/nodejs/node/pull/51799
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
NIST SP 800-131A Rev. 1 has been withdrawn. Replace the reference with a
link to NIST SP 800-131A Rev. 2.
PR-URL: https://github.com/nodejs/node/pull/49316
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Compromised algorithms will never again be recommended, so remove the
qualifier "currently".
PR-URL: https://github.com/nodejs/node/pull/49300
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
The DiffieHellman class is an old and thin wrapper around certain
OpenSSL functions, many of which are deprecated in OpenSSL 3.0. Because
the Node.js API mirrors the OpenSSL API, it adopts some of its
peculiarities, but the Node.js documentation does not properly reflect
these. Most importantly, despite the documentation saying otherwise,
diffieHellman.generateKeys() does not generate a new private key when
one has already been set or generated. Based on the documentation alone,
users may be led to misuse the API in a way that results in key reuse,
which can have drastic negative consequences for subsequent operations
that consume the shared secret.
These design issues in this old API have been around for many years, and
we are not currently aware of any misuse in the ecosystem that falls
into the above scenario. Changing the behavior of the API would be a
significant breaking change and is thus not appropriate for a security
release (nor is it a goal.) The reported issue is treated as CWE-1068
(after a vast amount of uncertainty whether to treat it as a
vulnerability at all), therefore, this change only updates the
documentation to match the actual behavior. Tests are also added that
demonstrate this particular oddity.
Newer APIs exist that can be used for some, but not all, Diffie-Hellman
operations (e.g., crypto.diffieHellman() that was added in 2020). We
should keep modernizing crypto APIs, but that is a non-goal for this
security release.
The ECDH class mirrors the DiffieHellman class in many ways, but it does
not appear to be affected by this particular peculiarity. In particular,
ecdh.generateKeys() does appear to always generate a new private key.
PR-URL: https://github.com/nodejs-private/node-private/pull/426
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
CVE-ID: CVE-2023-30590
When using OpenSSL 3, Node.js supports FIPS 140-2 when used with an
appropriate OpenSSL 3 provider. It is no longer necessary to rebuild
Node.js with different build time options.
Add a section on how to configure Node.js to use an OpenSSL 3 FIPS
provider to the documentation for the `crypto` module.
PR-URL: https://github.com/nodejs/node/pull/48194
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Remove broken link to deprecated keygen element.
Replacing the link with something to the relevant
part of the HTML spec might be OK, but I don't think
it's necessary. People who need to know will find it
and everyone else should be discouraged from using
this.
Support for the keygen element was removed from Chrome in 2017
and removed from Firefox in 2019. We might consider deprecating
and removing support ourselves, or at least marking the API
as legacy.
Refs: https://caniuse.com/?search=keygen
PR-URL: https://github.com/nodejs/node/pull/48176
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Add a reference to potential problems with using strings as HMAC keys.
Also advise against exceeding the underlying hash function's block size
when generating HMAC keys from a cryptographically secure source of
entropy.
Refs: https://github.com/nodejs/node/pull/48052
Refs: https://github.com/nodejs/node/pull/37248
PR-URL: https://github.com/nodejs/node/pull/48121
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The examples for generateKey() and generateKeySync() generate 64-bit
HMAC keys. That is inadequate for virtually any HMAC instance. As per
common NIST recommendations, the minimum should be roughly 112 bits, or
more commonly 128 bits.
Due to the design of HMAC itself, it is not unreasonable to choose the
underlying hash function's block size as the key length. For many
popular hash functions (SHA-256, SHA-224, SHA-1, MD5, ...) this happens
to be 64 bytes (bytes, not bits!). This is consistent with the HMAC
implementation in .NET, for example, even though it provides virtually
no benefit over a 256-bit key.
PR-URL: https://github.com/nodejs/node/pull/48052
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48064
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Deokjin Kim <deokjin81.kim@gmail.com>
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48063
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Deokjin Kim <deokjin81.kim@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Citing 76b0bdf720 from 2012, "only use
this as a temporary measure."
Getting or setting DEFAULT_ENCODING has emitted a warning ever since
Node.js 10, so it seems appropriate to remove it in Node.js 20 five
years later. The last Node.js version that did not emit a warning
reached its end-of-life status at the end of 2019.
This commit only removes the public API so that the change can land in
time for Node.js 20.
Refs: https://github.com/nodejs/node-v0.x-archive/pull/4179
Refs: https://github.com/nodejs/node/pull/18333
PR-URL: https://github.com/nodejs/node/pull/47182
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Beth Griggs <bethanyngriggs@gmail.com>
Reviewed-By: Erick Wendel <erick.workspace@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
There is no point in documenting this legacy behavior, which will emit a
warning when used.
PR-URL: https://github.com/nodejs/node/pull/47181
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This constant was likely introduced for feature detection, but it has
been pointless for a long time.
1. I am not aware of any possible Node.js build configuration (on any
recent/supported release line) that would have crypto.constants but
not crypto.constants.ALPN_ENABLED.
2. There is no evidence of this constant being used for feature
detection in the ecosystem. In fact, both internal and external type
definitions for crypto.constants simply assume that the constant
exists.
3. There is no good reason for any modern TLS stack to not support ALPN.
It looks like ALPN might have been optional in much earlier versions
of OpenSSL, but all recent versions of OpenSSL unconditionally
support ALPN as far as I can tell.
Refs: https://github.com/nodejs/node/pull/46956
PR-URL: https://github.com/nodejs/node/pull/47028
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
These 14 options do not have any effect in any supported version of
OpenSSL.
PR-URL: https://github.com/nodejs/node/pull/46954
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The old 1.0.2 docs do not exist anymore; link to the same file for
OpenSSL 3.0 instead.
PR-URL: https://github.com/nodejs/node/pull/46953
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/45640
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This option has existed ever since generateKeyPair was added in 2019 or
so, but I apparently forgot to document it.
PR-URL: https://github.com/nodejs/node/pull/45523
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
These MODP groups should not be used by new applications, and existing
applications should attempt to migrate to stronger groups (or different
key exchange mechanisms).
Some applications still rely on these particular groups, so Node.js will
likely maintain support, directly or indirectly, for the foreseeable
future.
Refs: https://github.com/nodejs/node/issues/44539
PR-URL: https://github.com/nodejs/node/pull/44588
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
As a first, small step toward deprecating modp1, stop using it in an
example that users might copy.
Refs: https://github.com/nodejs/node/issues/44539
PR-URL: https://github.com/nodejs/node/pull/44585
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: theanarkh <theratliter@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The current documentation clearly states that createCipher() and
createDecipher() should not be used with ciphers in counter mode, but
(1) this is an understatement, and (2) these functions are
(semantically) insecure for ciphers in any other supported block cipher
mode as well.
Semantic security requires IND-CPA, but a deterministic cipher with
fixed key and IV, such as those generated by these functions, does not
fulfill IND-CPA.
Are there justified use cases for createCipher() and createDecipher()?
Yes and no. The only case in which these functions can be used in a
semantically secure manner arises only when the password argument is
not actually a password but rather a random or pseudo-random sequence
that is unpredictable and that is never reused (e.g., securely derived
from a password with a proper salt). Insofar, it is possible to use
these APIs without immediately creating a vulnerability. However,
- any application that manages to fulfill this requirement should also
be able to fulfill the similar requirements of crypto.createCipheriv()
and those of crypto.createDecipheriv(), which give much more control
over key and initialization vector, and
- the MD5-based key derivation step generally does not help and might
even reduce the overall security due to its many weaknesses.
Refs: https://github.com/nodejs/node/pull/13821
Refs: https://github.com/nodejs/node/pull/19343
Refs: https://github.com/nodejs/node/pull/22089
PR-URL: https://github.com/nodejs/node/pull/44538
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
