这是一篇关于应用密码学的博客文章，重点关注在数据库或文件系统中静态加密数据的 Web 和云应用。

• 教训与观点：在 AWS 加密部门工作时了解到，静态加密的威胁模型常不明确，多数软件开发人员对面临的风险理解不清，虽不能绝对认同“静态加密是安全戏法”的观点，但其中有一定道理。作者在该领域有丰富经验，如设计相关 PHP 库、提出 PASETO 等，致力于让密码学易用且不易误用。
• 为何使用静态加密：主要讨论 Web 应用和云服务中的静态加密这一用例，因其能保护敏感数据。全磁盘加密虽可防止磁盘丢失时数据泄露，但对于在线攻击下的服务器端静态加密作用有限，在线攻击时全磁盘加密形同明文。所以应将存储大量数据的系统或组件围起来，不让明文越界，即使用静态加密。
• 静态加密的定义与类型：静态加密与传输加密相对，通常指 Web 应用或云服务在将数据存储到数据库等之前进行的加密操作。客户端加密指在系统架构外加密数据，一般由应用服务器进行批量加密。

• 客户端加密的安全考虑：

  • 密钥管理：这是复杂的问题，对于集中式服务，云密钥管理服务（如 AWS KMS、Google CloudKMS 等）并带有审计日志是较好的答案，后续会详细讨论。
  • 加密技术：一般应使用 AEAD 构造（如 AES-GCM 或 XChaCha20-Poly1305），若存储多客户数据需使用密钥承诺（如通过 stapling HKDF 到协议中），避免自建自定义的承诺 AEAD 方案以免引入规范风险。
  • 防止“困惑代理”攻击：即使使用安全的加密和密钥管理，仍存在针对静态加密方案的简单攻击，即通过复制并替换加密数据来获取他人的明文数据。缓解方法是使用 AAD 机制将密文与其上下文绑定，如在 AWS KMS 中可使用加密上下文。
  • 示例说明：以简单的 Web 应用为例，使用 AES-GCM 加密数据，展示了“困惑代理”攻击的过程，如替换用户数据。还提到 CipherSweet 库在处理该问题上的演变，从早期版本到 4.7.0 版本逐步完善对“困惑代理”攻击的防范。
• 非数据库场景：静态加密的“困惑代理”攻击问题不仅存在于数据库，在存储加密数据的 S3 桶等场景中也存在，需要某种形式的上下文绑定机制来防止攻击，即要验证访问模式。
• 现状与改进：软件安全中的静态加密问题大多未被广泛知晓或理解，导致利益相关者对安全要求存在分歧。可通过传播静态加密的细微差别、向供应商询问如何减轻“困惑代理”攻击风险、查看供应商的威胁模型文档等方式来改善情况，同时开发者应学习威胁建模。
• 总结与思考：作者不称自己有静态加密的所有答案，希望读者能提出正确问题。并对发布后收到的关于未提及某些特定内容的反馈进行了说明，强调文章重点及范围。

总之，静态加密虽重要但常被忽视和误解，需要开发者重视并仔细思考。