rsa-oaep + aes-gcm 混合加密是当前 web 端最可行方案，因 rsa-oaep 有长度限制（2048 位密钥仅支持约 214 字节），无法加密长消息，而 aes-gcm 负责主体加密、rsa-oaep 加密临时密钥，兼顾效率与兼容性。
直接用 RSA-OAEP + AES-GCM 混合加密，是当前 Web 端最可行、浏览器兼容性好、且符合 NIST 和 W3C 安全推荐的方案。别硬扛纯 RSA 加密长消息，会失败或被截断。
为什么不能只用 RSA-OAEP 加密全部数据
RSA-OAEP 本身有严格长度限制：2048 位密钥最多只能加密约 214 字节原始数据（SHA-256 + OAEP 填充后）。超过就抛 OperationError: Data too large。实际业务中一条消息动辄几 KB，纯 RSA 根本不可行。
- 浏览器不报错但静默截断 —— 这是最危险的情况，你可能根本没意识到数据损坏
- 即使降级用 3072 或 4096 位密钥，性能下降明显，且移动端生成/解密耗时翻倍
- Web Crypto API 对 RSA-OAEP 的
modulusLength最高只保证到 4096，部分旧版 Safari 不支持 >2048
混合加密的正确组装方式
核心逻辑是：用 AES-GCM 加密消息主体，再用对方公钥加密这个临时 AES 密钥（即“数字信封”）。接收方先解封密钥，再解密内容。
加密货币综合分析工具，集成OKX、Binance数据，提供行情、技术分析、交易信号、资金流向、仓位管理、DCA计划、风险计算。触发词：分析BTC、行情查询、交易信号、仓位计算、DCA计划、巨鲸追踪、风险评估。
-
AES-GCM必须用随机iv（至少 12 字节），每次加密都调用crypto.getRandomValues(new Uint8Array(12))，绝不能复用 - 导出 AES 密钥时必须用
crypto.subtle.exportKey("jwk", aesKey)，再用RSA-OAEP加密整个 JWK 字符串，而不是只加密keyData - 最终传输结构建议为 JSON 对象：
{ "iv": "...", "ciphertext": "...", "encryptedKey": "...", "tag": "..." }—— 其中tag是 AES-GCM 自动附带的认证标签，必须一并传输
密钥持久化与私钥保护的关键细节
私钥一旦生成，就不能再导出为可读格式；crypto.subtle.exportKey("jwk", privateKey) 在非 extractable 情况下会直接拒绝，这是设计使然，不是 bug。
- 存储私钥优先用
IndexedDB（配合encrypt操作加一层密码保护），sessionStorage仅限单次会话临时场景 - 若用户设置密码保护私钥，务必用
PBKDF2衍生密钥，迭代次数 ≥ 100000，盐值单独存且不可复用 - 导入公钥时，必须显式指定
format: "spki"，否则importKey会静默失败 —— 尤其当后端返回 PEM 格式时，要先剥离头尾、base64 解码再传入
常见跨浏览器兼容性陷阱
Chrome 和 Firefox 对 RSA-OAEP 支持完整，但 Safari（截至 iOS 17.5 / macOS 14.5）仍不支持 hash: "SHA-384" 或 "SHA-512"，强制指定会抛 NotSupportedError。
- 生产环境统一锁定
hash: "SHA-256"，别为了“更安全”乱升版本 -
generateKey的publicExponent必须是new Uint8Array([0x01, 0x00, 0x01])（即 65537），Safari 对其他值（如 [1, 0, 0, 1]）兼容性差 - Edge 110+ 已完全对齐标准，但旧版 EdgeHTML 引擎已淘汰，无需再适配
真正容易被忽略的是：AES-GCM 的 tag 长度默认为 128 位，但解密时必须原样传入，少一个字节或类型不对（比如误传成 string 而非 Uint8Array）就会报 InvalidAccessError，且错误信息毫无提示性。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
