[Feature] Implement crypto.createCipheriv

[vicb]

crypto.createCipheriv is required by Next Auth.

See opennextjs/opennextjs-cloudflare#206

Can we prioritize the implementation of the API?

@jasnell

The crypto APIs are used by Next from crypto-utils.ts

What is used by Next is:

// * Ciphers
// * [x] crypto.createCipheriv(algorithm, key, iv[, options])
// * [x] crypto.createDecipheriv(algorithm, key, iv[, options])

with the aes-256-gcm algo

[jasnell]

Was can likely prioritize more of the node:crypto APIs in 1Q

[albertocavalcante]

Hi there! Do you know if there's any workaround in the meantime? Thanks!

[jasnell]

The only workaround is to use web crypto.

[vicb]

The only workaround is to use web crypto.

The code is the Nextjs lib, not in user code so changing to use webcrypto is not trivial.
I would way your only chance is to check if you can setup Next to use a different algo.

[Macil]

Small addition to the original post: in the issue opennextjs/opennextjs-cloudflare#206 using the package next-auth, the problem can (also?) happen from a call to crypto.createCipheriv with the "aes-256-cbc" algorithm (through next-auth/packages/core/src/jwt.ts which eventually calls into jose/src/runtime/node/encrypt.ts).

[vicb]

Small correction to the original post: in the issue opennextjs/opennextjs-cloudflare#206 using the package next-auth, the relevant call to crypto.createCipheriv actually happens with the "aes-256-cbc" algorithm (through next-auth/packages/core/src/jwt.ts which eventually calls into jose/src/runtime/node/encrypt.ts).

I'm pretty sure I tested it with Next 15, any chance you are using a different version than the one of the original bug report?

Anyway we should still implement the algo.

Thanks for your message.

[Macil]

Oh sorry I was very zoned into thinking about my specific case while writing that out the first time, and I'm definitely not sure now that spot of code is the only relevant one, especially considering different versions and configurations. I've added a reproduction case on that original issue thread now.

[arnavgupta00]

Hi there! Do you know if there's any workaround in the meantime? Thanks!

I created this Repo, This approach addresses the crypto.createCipheriv limitation by substituting Node.js's crypto module with the Web Crypto API

Check it out, might be of help

[vicb]

Hi there! Do you know if there's any workaround in the meantime? Thanks!

I created this Repo, This approach addresses the crypto.createCipheriv limitation by substituting Node.js's crypto module with the Web Crypto API

Check it out, might be of help

Thanks @arnavgupta00!

If I understand correctly, the main point is to override the encode/decode methods here:

https://github.com/arnavgupta00/deployment-cf-workers-prisma-nextauth/blob/32aa1768edfef8ea112cd5065e2e9c07d5506866/src/lib/authConfig.ts#L43-L46

[arnavgupta00]

Hi there! Do you know if there's any workaround in the meantime? Thanks!

I created this Repo, This approach addresses the crypto.createCipheriv limitation by substituting Node.js's crypto module with the Web Crypto API
Check it out, might be of help

Thanks @arnavgupta00!

If I understand correctly, the main point is to override the encode/decode methods here:

https://github.com/arnavgupta00/deployment-cf-workers-prisma-nextauth/blob/32aa1768edfef8ea112cd5065e2e9c07d5506866/src/lib/authConfig.ts#L43-L46

Yes, that's correct, I've overridden the default encode and decode of next-auth . By implementing custom encode and decode functions, we can handle JWT operations securely within the Cloudflare environment.

[vicb]

Thanks @arnavgupta00, do you know if this would work the same with Next15? (I'm planning to add some docs until the workerd implementation is ready)

[arnavgupta00]

Thanks @arnavgupta00, do you know if this would work the same with Next15? (I'm planning to add some docs until the workerd implementation is ready)

Yes, based on the Next.js 15 release documentation, the integration should function similarly. Ensure your tsconfig.json includes:

{
  "compilerOptions": {
    "module": "esnext",
    "target": "es2017"
  }
}

This configuration enables top-level await as used in this File, but you can easily find out a way around that.

[vicb]

Yes, based on the Next.js 15

Thanks!

This line looks fishy as process.env is not always populated at top level - only guaranteed in the request context. Ping me on Discord to discuss more so that we don't add more OpenNext related messages to this thread, thanks (or on the OpenNext issue)