Unknown ciphers: aes-256-cfb, aes-128-cfb

• Output of node_modules/.bin/electron --version: 4.0.0
• Operating System (Platform and Version): Windows 10
• Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): v3.x.x

Expected Behavior
Generally , invoke crypto.createCipheriv () that should return a Cipheriv Object.

Actual behavior
When I call crypto.createCipheriv() , it will response me a error that is unknown cipher .
But If I run this program(test code ) alone by node cmd. (ex. node test.js ) that it work.
So I don't think it is a node10 problem.

To Reproduce
sample code
in main.js

const crypto = require('crypto')
const methodName = 'aes-256-cfb'
const key =  'nMvTdb7VXMPudFWH'
const iv = crypto.randomBytes(16)
const cipher = crypto.createCipheriv(methodName, key, iv)
console.log(cipher)

Response:
in Electron 4 or more newer

unknown cipher

in Electron 3.x , more older or run alone by node cmd

 Cipheriv {
  _handle: {},
  _decoder: null,
  _options: undefined,
  writable: true,
  readable: true }  

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[shiftkey]

@DessertBoy which version of Node 10 are you testing on locally that works with your sample code? I ask because Electron 3 is based on Node 10.2 and Electron 4 is based on Node 10.11, so having more data points here about what works and what doesn't will help us troubleshoot the issue better...

@DessertBoy which version of Node 10 are you testing on locally that works with your sample code? I ask because Electron 3 is based on Node 10.2 and Electron 4 is based on Node 10.11, so having more data points here about what works and what doesn't will help us troubleshoot the issue better...

@shiftkey I have tried v10.2.0 and v10.11.0 on locally with sample code in test.js , and execute the sample code via node cmd. As a result both versions can succeed
If I run sample code in main.js via Electron 4 that will fail. but Electron 3 is ok.
so I don't think that is Node10 version problem.

[pbca26]

It seems that the problem is far bigger than just missing cipher

I compared Electron 3, Electron 4 and NodeJS 10.11.0

Electron 3/NodeJS 10.11.0

const crypto = require('crypto')
const hashes = crypto.getHashes();
console.log(hashes);

[ 'RSA-MD4',
'RSA-MD5',
'RSA-MDC2',
'RSA-RIPEMD160',
'RSA-SHA1',
'RSA-SHA1-2',
'RSA-SHA224',
'RSA-SHA256',
'RSA-SHA384',
'RSA-SHA512',
'blake2b512',
'blake2s256',
'md4',
'md4WithRSAEncryption',
'md5',
'md5-sha1',
'md5WithRSAEncryption',
'mdc2',
'mdc2WithRSA',
'ripemd',
'ripemd160',
'ripemd160WithRSA',
'rmd160',
'sha1',
'sha1WithRSAEncryption',
'sha224',
'sha224WithRSAEncryption',
'sha256',
'sha256WithRSAEncryption',
'sha384',
'sha384WithRSAEncryption',
'sha512',
'sha512WithRSAEncryption',
'ssl3-md5',
'ssl3-sha1',
'whirlpool' ]

Electron 4

var crypto = require('crypto')
const hashes = crypto.getHashes();
console.log(hashes);

[ 'md4', 'md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512' ]

quite a lot of hash functions just disappeared in Electron 4

[shiftkey]

For reference, I checked the similar crypto.getCiphers() function on macOS (not Windows like the original reporter) in Electron 3.0.13 (135 listed):

And then compared it to what's now in 4.0.0 (16 listed):

[ca333]

confirm the above issue - seems the v4 incl. crypto module got "rid of" most hash funcs which breaks backwards compatiblity in our software.

@ca333 yes. That's it.

@shiftkey @pbca26 Thank you. It seems that the problem is this. But I want to know why is there such a difference ? or Is this just a bug in Electron 4 ? and Can I think this is the meaning ?

[shiftkey]

@DessertBoy I'm not sure offhand. You'd have to look into how the Electron team are building and packaging Node into Electron - https://github.com/electron/node is the repository where that happens

[nornagon]

The root cause here is that we switched from OpenSSL in Electron 3 to BoringSSL in Electron 4.

In Electron 3, Chromium uses BoringSSL and Node uses OpenSSL. In Electron 4, we only ship one SSL library, and that's BoringSSL. The main reason for this is that Electron 4 is a single static binary, and BoringSSL and OpenSSL cannot coexist in the same binary because their symbols conflict (e.g. both of them define a function called SSL_CTX_use_certificate).

In general, BoringSSL is more focused on providing up-to-date and secure ciphers than it is concerned with backwards compatibility, so if you really need OpenSSL specifically, I think the best path forward would be to have OpenSSL available as a native node module. That way the vast majority of folks that don't need access to obscure cipher suites can use the smaller, already-bundled BoringSSL, and anyone who needs OpenSSL specifically can install it from npm.

That said, there is some precedent for BoringSSL adding support for less-commonly-used ciphers and cipher options via the decrepit module, for example aes-128-cfb. Electron does not compile all the decrepit sources by default—only just enough to get Node to build—but we could add more relatively easily. We're generally happy to support and expose what BoringSSL already supports but doesn't necessarily expose to the EVP APIs that Node calls (i.e. EVP_CIPHER_do_all_sorted and EVP_get_cipherbyname). However, there are some cipher suites that BoringSSL doesn't support, for instance Camellia. See decrepit/ in the BoringSSL source for features that BoringSSL supports but doesn't expose by default (usually because they're underused or insecure).

Here's an example of a patch that would add support for the aes-{128,256}-cfb cipher suites to BoringSSL's compatibility layer. (Would also need to add cfb.c to the list of decrepit modules that Electron includes.)

[nornagon]

Also, as for the list of hashes, OpenSSL adds a lot of aliases to that list, so e.g. RSA-SHA1, RSA-SHA1-2, sha1WithRSAEncryption and ssl3-sha1 are all aliases of sha1.

Digest algorithms present in OpenSSL that are not present in BoringSSL (decrepit or otherwise):

• mdc2 (aka RSA-MDC2, mdc2WithRSA)
• blake2 (its variants blake2b512, blake2s256)
• whirlpool

All the other elements in the list produced by crypto.getHashes() are just aliases.

ripemd160 (aka RSA-RIPEMD160, ripemd160, ripemd160WithRSA, rmd160) is present in BoringSSL's decrepit module and not currently built in Electron.

[sschiessl-bcp]

Is there any fix to this problem? thanks

Anything? We would also be very interested in a fix, especially for Electron 6.

[nornagon]

I've updated the title of this issue to refer to the initially-requested ciphers aes-256-cfb and aes-128-cfb, which are available & working in current versions of Electron. If you're having trouble with a different cipher, please open a new issue with the details of the problem you're experiencing.

[franzwilhelm]

@nornagon Thank you for some very clear answers in this thread! I'm in need of aes-128-ccm, not cfb for a project I'm currently working on. I don't really rely on having that installed into the electron binaries, if there's an easy way to polyfill the cipher into the crypto library included with the latest electron versions. How would I do such a thing? I'm currently relying on a package importing crypto through require('crypto'), and I need the cipher to be available through that import

[nornagon]

@franzwilhelm as requested in my previous comment, please open a new issue for new ciphers.

[PeterRao]

Never mind. Was able to achieve compatibility using aes-256-cbc.

How did you solve it