HTML5 的 Web Crypto API 不支持 CMAC 算法，因其未被 W3C 标准采纳；需依赖第三方 JS 库（如 asmcrypto.js）手动实现或改用原生支持的 HMAC-SHA256 替代。
HTML5 本身不原生支持 CMAC（Cipher-based Message Authentication Code）算法，因为 CMAC 是基于分组密码（如 AES）构造的消息认证码，属于底层密码学操作，而标准 Web Crypto API 目前（截至 2026 年初）**尚未纳入 CMAC 算法规范**。浏览器的 window.crypto.subtle 接口支持 HMAC、AES-GCM、RSA-PSS 等，但不支持 CMAC 或 OMAC。
为什么不能直接在 HTML5 中用 Web Crypto 调用 CMAC
Web Crypto API 的 generateKey、sign、verify 等方法仅定义了有限的算法集合，CMAC 未被 W3C 标准采纳。即使使用 AES-CBC 或 AES-KW 等 AES 模式，也无法直接复现 CMAC 的密钥派生（K1/K2）、块填充与异或逻辑——这些必须手动实现，且需严格遵循 NIST SP 800-38B 规范。
可行的替代路径：纯 JS 实现（需谨慎评估）
若业务强依赖 CMAC（例如对接国密合规系统或特定硬件模块），可考虑以下方式，但须注意安全与性能边界：
- 采用成熟、审计过的 JavaScript 密码库（如 asmcrypto.js 或 micro-cmac），它们已封装 AES-128/192/256 下的 CMAC 计算逻辑，支持 Uint8Array 输入与同步计算
- 密钥必须为固定长度（如 AES-128 对应 16 字节），不可直接传入字符串；需先用 UTF-8 编码再转为 Uint8Array
- 消息须按 16 字节分块处理，末块需特殊填充（若非整除）；库通常自动处理，但需确认其是否兼容 ISO/IEC 9797-1 方式1
- 避免在前端长期持有高敏感密钥；CMAC 密钥如用于服务端验证，建议由后端生成并下发短期 token，前端仅参与计算不保管主密钥
更推荐的 HTML5 原生方案：用 HMAC 替代 CMAC
绝大多数场景下，HMAC-SHA256 完全可替代 CMAC 实现消息完整性校验，且具备原生支持、高性能、广泛互操作等优势：
- 调用
crypto.subtle.importKey导入对称密钥（格式为 raw，algorithm 为{"name": "HMAC", "hash": "SHA-256"}） - 用
crypto.subtle.sign对消息 Uint8Array 执行签名，得到固定 32 字节 MAC 值 - 服务端用相同密钥和算法验证；双方无需共享 AES 实现细节，规避 CMAC 手动实现风险
- 若需国密合规，可选用 SM3-HMAC（需扩展库），但标准 Web Crypto 仍不支持 SM 系列
实际开发中的关键提醒
不要因“CMAC 更‘密码学原生’”而强行引入非标实现。真实项目中：
- CMAC 多用于嵌入式设备、智能卡、国密模块等受限环境，Web 端极少作为首选
- 若后端强制要求 CMAC 输入，建议将校验逻辑下沉至可信后端：前端上传原始数据 + 时间戳 + 随机 nonce，由后端完成 CMAC 计算与比对
- 所有前端生成的 MAC 值都不可信——攻击者可篡改 JS 逻辑；完整性校验最终必须由服务端闭环验证
