[Bug]: AES-KW through main process crypto.subtle causes OperationError

[LiranCohen]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

29.1.5

What operating system are you using?

macOS

Operating System Version

Sonoma 14.4.1

What arch are you using?

arm64 (including Apple Silicon)

Last Known Working Electron version

No response

Expected Behavior

Support of crypto.subtle.wrapKey for AES-KW given the native support in underlying NodeJS

Actual Behavior

$ electron . --trace-warnings
(node:72602) UnhandledPromiseRejectionWarning: OperationError: The operation failed for an operation-specific reason
    at new DOMException (node:internal/per_context/domexception:53:5)
    at __node_internal_ (node:internal/util:695:10)
    at onDone (node:internal/crypto/util:420:19)
    at node:internal/crypto/util:434:7
    at new Promise (<anonymous>)
    at jobPromise (node:internal/crypto/util:428:10)
    at asyncAesKwCipher (node:internal/crypto/aes:145:10)
    at Object.aesCipher (node:internal/crypto/aes:212:27)
    at cipherOrWrap (node:internal/crypto/webcrypto:918:12)
    at SubtleCrypto.wrapKey (node:internal/crypto/webcrypto:715:10)
    at emitUnhandledRejectionWarning (node:internal/process/promises:201:15)
    at processPromiseRejections (node:internal/process/promises:297:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)
(node:72602) OperationError: The operation failed for an operation-specific reason
    at new DOMException (node:internal/per_context/domexception:53:5)
    at __node_internal_ (node:internal/util:695:10)
    at onDone (node:internal/crypto/util:420:19)
    at node:internal/crypto/util:434:7
    at new Promise (<anonymous>)
    at jobPromise (node:internal/crypto/util:428:10)
    at asyncAesKwCipher (node:internal/crypto/aes:145:10)
    at Object.aesCipher (node:internal/crypto/aes:212:27)
    at cipherOrWrap (node:internal/crypto/webcrypto:918:12)
    at SubtleCrypto.wrapKey (node:internal/crypto/webcrypto:715:10)

Testcase Gist URL

https://gist.github.com/LiranCohen/9c93d27ae218f60042932eba271af75b

Additional Information

Reviving this auto-closed issue:
#36256

[codebytere]

@LiranCohen this is unfortunately by design and not something we're currently likely to change. Node.js proper uses OpenSSL to underpin crypto, whereas Electron uses BoringSSL: a fork of OpenSSL from Chromium pared down significantly compared to Node.js. The actual error here is that the cipher is unsupported, which is a choice made intentionally by BoringSSL. It's implemented in WebCrypto, however, so you're able to use it in the renderer process if you so choose.

[shamilovtim]

@LiranCohen this is unfortunately by design and not something we're currently likely to change. Node.js proper uses OpenSSL to underpin crypto, whereas Electron uses BoringSSL: a fork of OpenSSL from Chromium pared down significantly compared to Node.js. The actual error here is that the cipher is unsupported, which is a choice made intentionally by BoringSSL. It's implemented in WebCrypto, however, so you're able to use it in the renderer process if you so choose.

@codebytere If it's supported in the renderer process (via webcrypto) what is the distinction and and reasoning for keeping it unsupported in the Node.js process? Node also has crypto.webcrypto so this isn't making sense.

As a consequence of this Electron has made a conscious choice to be the only platform that doesn't support keywrap by pointing responsibility back to BoringSSL, even though BoringSSL does support keywrap on browser: https://commondatastorage.googleapis.com/chromium-boringssl-docs/aes.h.html#AES_wrap_key. Logically this isn't adding up.