用途：审计应用中密码学的实现方式，包括算法选择、参数、模式与调用顺序，找出那些把正确原语用成脆弱系统的实现问题，属于比基础审计更细的实现层审查。
主要能力： 一、算法与模式检查。对称加密建议 AES-256-GCM 或 ChaCha20-Poly1305，拒绝 AES-ECB、无 HMAC 的 CBC/CTR、DES/3DES、RC4、Blowfish；非对称建议 Ed25519/X25519，RSA 需 OAEP/PSS 且 3072 位以上，不用 PKCS#1 v1.5 加密；通用哈希用 SHA-256/SHA-3/BLAKE2/BLAKE3，口令哈希用 Argon2id、scrypt 或 bcrypt（cost ≥ 12）；MAC 用 HMAC-SHA256。 二、密钥派生：口令用 Argon2id、PBKDF2-HMAC-SHA256（≥600000 次迭代）或 scrypt（N=2^17, r=8, p=1）；高熵密钥材料用 HKDF-SHA256。 三、IV/nonce：GCM 同一密钥下 nonce 绝不重用，可用 96 位随机 nonce，高流量场景改用 AES-GCM-SIV；CBC 用随机 16 字节 IV；CTR 计数器不得重复。 四、认证加密与签名验证：始终使用认证模式，先校验 MAC 再解密，MAC 常量时间比较；JWT 必须用 jwt.verify 且校验 alg，注意 alg: none；Webhook 先验签再解析，使用时间戳容差（如 ±5 分钟）。 五、随机性与 TLS：使用 crypto.randomBytes、secrets.token_bytes、crypto/rand、SecureRandom；TLS 1.3 优先、最低 1.2，仅 ECDHE + AEAD 套件，启用证书校验、pinning、HSTS、OCSP stapling，可用 testssl.sh 或 sslyze --regular 测试。 六、密钥生命周期：密钥存于 HSM/云 KMS，采用信封加密、定期轮换、版本记录与吊销预案；给出 Rails、Django、Node、iOS、Android 的常见库建议。
使用方式：由用户提供代码与配置，按清单逐项审查，并在运行时验证（加解密往返、TLS 版本、KMS 加解密权限）。输出格式含摘要、发现表（ID/严重级别/组件/问题/CWE）、逐条详情、TLS 状况、密钥清单与优先级建议。
适用场景：对自研或既有系统的加密实现做专项审查，作为 OWASP 类审计的补充，配合密钥存储与 IAM 审计。
限制：仅审计用户提供的代码与配置，不协助削弱密码学或植入后门；TLS 测试需获授权；若发现自定义密码学等根本性缺陷，建议替换而非修补；后量子迁移仅提示跟踪 NIST 标准化，不建议未标准化的具体原语。