AES decrypt() ignores the supplied mode option, resulting in inconsistent CBC behavior

[krishna28004]

Description

The AES decrypt() API accepts a CipherOptions object containing a mode field, but the supplied mode is never used during decryption.

As a result, calling:

decrypt(input, key, { mode: "CBC" })

follows the same execution path as any other mode, leading to behavior that differs from what callers expect when requesting CBC.

This affects downstream functionality that relies on the mode option, including the Padding Oracle Simulator.

---

Evidence

Public API

decrypt() accepts a CipherOptions object:

export function decrypt(
  input: string,
  key: string,
  options: CipherOptions = {}
)

CipherOptions defines:

mode?: string

---

Current Execution Flow

The decryption path receives the options object but never checks or forwards options.mode.

if (options.instrument) {
  result = aesInstrumented(inputBytes, keyBytes, true)
} else {
  result = aesFast(inputBytes, keyBytes, true)
}

Both execution paths ignore the supplied mode.

---

Reproduction

1. Call:

decrypt(ciphertext, key, {
  mode: "CBC",
  encoding: "hex"
})

2. Trace execution through aes.ts.

3. Observe that options.mode is never read or propagated.

---

Expected Behavior

The supplied mode should either:

• be honored during decryption, or
• be explicitly rejected if unsupported.

Ignoring a supported API option silently produces behavior that differs from caller expectations.

---

Actual Behavior

The supplied mode value is ignored without warning, and all requests follow the same decryption path.

This leads to inconsistent behavior for features that rely on CBC semantics, including the Padding Oracle Simulator.

---

Files

• lib/cipher/symmetric/aes.ts
• lib/attacks/paddingOracle.ts

[krishna28004]

Hi @csxark, I'd like to work on this issue. If approved, could you please assign it to me?

[csxark]

Hi! @krishna28004, I'm assigning this initiative to you.

A warm welcome to the CryptoViz project! We're excited to have you on board and truly appreciate your willingness to contribute. Looking forward to your creativity and meaningful contributions, especially from the branding perspective. Wishing you the very best, and happy contributing! 🚀

[krishna28004]

Hi @csxark !
While rebasing against the latest main, I found that AES mode support (CBC/CTR/CFB/OFB) has already been implemented
upstream, which makes my original fix obsolete. I don't want to submit a PR that conflicts with the new implementation. Would you prefer that I investigate the remaining invalid-mode fallback behavior, or should I pick another issue?

[csxark]

Hi @krishna28004,

In that case, let's close this PR. It appears that this issue has already been addressed, so there's no need to keep this one open. You can work on another issue instead.

I'll be closing this PR as a duplicate since there are no outstanding issues to resolve here. Thanks for your contribution!