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

Ok, I’ll use a try catch then.

Wouldn’t want someone’s app to break because of it, and bumping major version for a string change is silly.

Is it planned to add ripemd160 to electron from boringSSL? it is needed for some cryptocurrency-related libraries, like https://github.com/cryptocoinjs/hdkey/blob/master/lib/hdkey.js#L238

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

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

Closing this issue as all the ciphers/hashes mentioned here have been exposed (aes-{128,256}-cfb and ripemd160). If there are other ciphers or hashes you need, please open a new issue for the specific algorithm and we’ll see what we can do.

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

@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 So every single app that uses rmd160 (keeping in mind that NodeJS crypto uses aliases) will have to dance around with try catches every time a user tries to use their library in Electron?

Just making sure.

$ node -e "console.log(require('crypto').getHashes().filter(v => v.indexOf('160') > -1))"
[ 'RSA-RIPEMD160', 'ripemd160', 'ripemd160WithRSA', 'rmd160' ]

Edit: I have asked some coworkers using various versions of NodeJS, Linux, MacOS, Windows 10 etc. and everyone gets the same results as me above…

Which comes down to two choices:

1. The world changes for Electron. Every library who uses rmd160 must change. Best to get the word out to the entire open source world.
2. Electron maintains backwards compatibility for NodeJS libraries and adds aliases.

Don’t read into my words here. I am not implying anything.

Just want to clarify that 1 is the proper way forward? If so I will go ahead and add a try catch to our library.

rmd160 is an alias for ripemd160. We won’t be adding additional aliases for ciphers that are already available.

ripemd160是一个摘要，而不是一个密码。它列在crypto.getHashes()版本> = 4.0.4上。

Excuse me, will you support ‘rmd160’ in the follow-up?

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.)