Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto: doc-only deprecate createCipher/Decipher #19343

Closed

Conversation

tniessen
Copy link
Member

createCipher and createDecipher are cryptographically weak and can cause severe security issues when used improperly, there are hundreds of examples on GitHub alone. There was #13941 but it was discontinued due to the author becoming inactive. Seeing that crypto.createCipher is widely used, the first step is to doc-only deprecate the pair of functions.

Another argument against having create(De|C)ipher is that they are unsupported in FIPS mode, not sure whether that's worth mentioning.

Checklist

@tniessen tniessen added the semver-major PRs that contain breaking changes and should be released in the next major version. label Mar 14, 2018
@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Mar 14, 2018
@tniessen tniessen added the crypto Issues and PRs related to the crypto subsystem. label Mar 14, 2018
@tniessen
Copy link
Member Author

cc @nodejs/crypto

avoided as they use a weak key derivation function (MD5 with no salt) and static
initialization vectors. It is recommended to derive a key using
[`crypto.pbkdf2()`][] and to use [`crypto.createCipheriv()`][] and
[`crypto.createDecipheriv()`][] to obtain the [`Cipher`] object.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"obtain the [`Cipher`] object" should probably be something like: "obtain [`Cipher`]/[`Decipher`] objects respectively"

@tniessen tniessen added this to the 10.0.0 milestone Mar 14, 2018
initialization vectors. It is recommended to derive a key using
[`crypto.pbkdf2()`][] and to use [`crypto.createCipheriv()`][] and
[`crypto.createDecipheriv()`][] to obtain the [`Cipher`][] and [`Decipher`][]
object, respectively.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-nit: object -> objects

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nano-nit: Remove the comma.

@lpinca
Copy link
Member

lpinca commented Mar 16, 2018

@lpinca lpinca added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 16, 2018
@tniessen tniessen force-pushed the deprecate-createcipher-doc-only branch from 1133daf to d40b2c8 Compare March 18, 2018 14:42
@tniessen
Copy link
Member Author

@tniessen tniessen requested a review from a team March 19, 2018 14:19
tniessen added a commit that referenced this pull request Mar 21, 2018
createCipher and createDecipher are cryptographically weak, can cause
severe security issues when used improperly and are unsupported in FIPS
mode.

PR-URL: #19343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
@tniessen
Copy link
Member Author

Landed in 81f88e3 with code DEP0106.

@tniessen tniessen closed this Mar 21, 2018
@tniessen tniessen removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 24, 2018
@tniessen tniessen added the deprecations Issues and PRs related to deprecations. label Apr 28, 2018
tniessen added a commit to tniessen/node that referenced this pull request Sep 6, 2022
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: nodejs#13821
Refs: nodejs#19343
Refs: nodejs#22089
nodejs-github-bot pushed a commit that referenced this pull request Sep 8, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
Fyko pushed a commit to Fyko/node that referenced this pull request Sep 15, 2022
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: nodejs#13821
Refs: nodejs#19343
Refs: nodejs#22089
PR-URL: nodejs#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>
RafaelGSS pushed a commit that referenced this pull request Sep 26, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
RafaelGSS pushed a commit that referenced this pull request Sep 26, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
RafaelGSS pushed a commit that referenced this pull request Sep 26, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 4, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 4, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 4, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 7, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 10, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
juanarbol pushed a commit that referenced this pull request Oct 11, 2022
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: #13821
Refs: #19343
Refs: #22089
PR-URL: #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>
guangwong pushed a commit to noslate-project/node that referenced this pull request Jan 3, 2023
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: nodejs/node#13821
Refs: nodejs/node#19343
Refs: nodejs/node#22089
PR-URL: nodejs/node#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>
guangwong pushed a commit to noslate-project/node that referenced this pull request Jan 3, 2023
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: nodejs/node#13821
Refs: nodejs/node#19343
Refs: nodejs/node#22089
PR-URL: nodejs/node#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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Issues and PRs related to the crypto subsystem. deprecations Issues and PRs related to deprecations. doc Issues and PRs related to the documentations. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants