crypto: warn if counter mode used in createCipher by shigeki · Pull Request #13821 · nodejs/node

@shigeki added crypto

Issues and PRs related to the crypto subsystem.

semver-major

PRs that contain breaking changes and should be released in the next major version.

labels

Jun 20, 2017

@nodejs-github-bot nodejs-github-bot added c++

Issues and PRs that require attention from people who are familiar with C++.

crypto

Issues and PRs related to the crypto subsystem.

labels

Jun 20, 2017

bnoordhuis

`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

@shigeki

bnoordhuis

tniessen

MylesBorins pushed a commit that referenced this pull request

Sep 12, 2017
`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

Fixes: #13801
PR-URL: #13821
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>

bnoordhuis pushed a commit to bnoordhuis/io.js that referenced this pull request

Oct 29, 2017
`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

Fixes: nodejs#13801
PR-URL: nodejs#13821
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>

bnoordhuis added a commit to bnoordhuis/io.js that referenced this pull request

Oct 29, 2017
The previous commit is a back-port of pull request nodejs#13821 to v6.x.
Its regression test does not apply to the v6.x branch (depends on
semver-major pull request nodejs#9405) so this commit adds a new test.

Refs: nodejs#13821
Refs: nodejs#9405

MylesBorins pushed a commit that referenced this pull request

Nov 14, 2017
`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

Backport-PR-URL: #16583
Fixes: #13801
PR-URL: #13821
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>

MylesBorins pushed a commit that referenced this pull request

Nov 21, 2017
`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

Backport-PR-URL: #16583
Fixes: #13801
PR-URL: #13821
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>

MylesBorins pushed a commit that referenced this pull request

Nov 28, 2017
`crypto.createCipher()` sets the fixed IV derived from password and it
leads to a security risk of nonce reuse when counter mode is used.
A warning is emitted when CTR, GCM or CCM is used in
`crypto.createCipher()` to notify users to avoid nonce reuse.

Backport-PR-URL: #16583
Fixes: #13801
PR-URL: #13821
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>

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>