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>
Explicitly document the attribute `Script.cachedDataRejected` in a
dedicated section.
Removes the documented option `produceCachedData` and the description
of `cachedDataRejected` in `vm.runInContext`, `vm.runInNewContext`,
and `vm.runInThisContext` as the created `vm.Script` instance is not
accessible from userland in these methods.
PR-URL: https://github.com/nodejs/node/pull/44451
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Currently, DebugSymbolsTest.ReqWrapList fails on PPC64LE when Node has
been configured with Link Time Optimization (LTO) and using RHEL 8.5
and gcc:
```console
$ . /opt/rh/gcc-toolset-11/enable
$ export CC='ccache gcc'
$ export CXX='ccache g++'
$ ./configure --enable-lto
$ make -j8 cctest
...
21:52:27 [ RUN ] DebugSymbolsTest.ReqWrapList
21:52:27 ../test/cctest/test_node_postmortem_metadata.cc:203: Failure
21:52:27 Expected equality of these values:
21:52:27 expected
21:52:27 Which is: 140736537072320
21:52:27 calculated
21:52:27 Which is: 1099680328560
21:52:27 [ FAILED ] DebugSymbolsTest.ReqWrapList (43 ms)
```
After looking into this is seems that the compiler is tampering with the
`last` variable when compiling with LTO enabled. This commit suggests
adding volatile to this variable to prevent the compiler from tampering
with it.
PR-URL: https://github.com/nodejs/node/pull/44341
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
RAND_bytes() may return 0 to indicate an error, in which case the buffer
might not have been filled with random data at all. Instead of ignoring
this case, let V8 use its own entropy source. Historically, this used to
be a weak source of entropy, but V8 now implements a proper source even
on Windows. And even if V8's own entropy source turns out to be weak, it
does not matter much: V8's PRNG itself is not cryptographically secure,
so even if it is seeded from a cryptographically secure entropy source,
it does not produce cryptographically secure random numbers.
PR-URL: https://github.com/nodejs/node/pull/44493
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
We already do this in some places. This adds the digest name to
remaining uses of ERR_CRYPTO_INVALID_DIGEST except for one occurrence in
crypto_sig.cc that would require significant refactoring due to the
unusual error handling there.
PR-URL: https://github.com/nodejs/node/pull/44468
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
When a new context with a different security token is entered, or
when no context is entered, `StackTrace::CurrentStackTrace` need to
be explicitly set with flag `kExposeFramesAcrossSecurityOrigins` to
avoid crashing.
PR-URL: https://github.com/nodejs/node/pull/44398
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
`Environment::GetCurrent` may not available in the context of OOM.
Removes the cyclic `Environment::GetCurrent` and `env->isolate()`
calls to ensure both `isolate` and `env` is present if available.
However, this behavior is not guaranteed. As
`Environment::GetCurrent` didn't allocate new handles in the heap,
when a Context is entered it can still get the valid env pointer.
Removes the unstable assertion of the absence of env in the test.
PR-URL: https://github.com/nodejs/node/pull/44398
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This flag was added back in 2013 to support postmortem debugging on
Linux but it has a pretty bad impact on performance (up to 10%) and
I don't think it's actually necessary to get meaningful stack traces.
Maybe with mdb but gdb and lldb seem to manage just fine.
Even if the flag is necessary for postmortem debugging, I don't think
it's appropriate to make performance for all users suffer for the
benefit of a fringe group.
PR-URL: https://github.com/nodejs/node/pull/44452
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Given that the divisor is not zero, the result of dividing unsigned
integers is an unsigned integer that is always rounded down, i.e.,
there is no need to call std::trunc(). Doing so unnecessarily yields
a floating-point number, requiring the result to be cast to an unsigned
integer again.
PR-URL: https://github.com/nodejs/node/pull/44467
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
On Windows it might take too long for the parent to start the
communication with a child process, so by the time the parent
starts its own timer, the child process might have already
completed running, and the parent in those tests won't have a
chance to terminate these child processes after the timeout.
To address this issue, raise the time for which the child is
supposed to run to make sure that the parent starts
its own timer before the child terminates in the tests.
Also, split the test into smaller ones to reduce the overhead.
PR-URL: https://github.com/nodejs/node/pull/44390
Refs: https://github.com/nodejs/reliability/issues/356
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Daeyeon Jeong