什么是数字信封？信封加密解析

对称加密（AES）很快——快到足以加密数 MB 的 PDF、合同和多媒体文件。但它要求双方事先共享同一个密钥，而这恰恰是你要把文档发给一个新联系人时最难解决的问题。

非对称加密（RSA、ECC）解决了密钥共享——任何人都能用公钥加密，只有持有者能解密。但它速度慢、载荷大小受限，直接加密整个文档不现实。

信封把两者结合起来：对称加密负责重活（文档本身），非对称加密负责小载荷（密钥）。在需要速度的地方用速度，在需要安全交换密钥的地方用安全——这正是 TLS、S/MIME 邮件、PGP 和云密钥管理系统普遍采用的标准模式。

数字信封回答的是「还有别人能读到吗？」它通过加密内容提供机密性。打开信封需要收件人的私钥，发送方无需预先共享任何秘密。

数字签名回答的是「这真的来自这个人吗？有没有被篡改？」它用签名者的私钥加密文档哈希，提供真实性与完整性。任何持有公钥的人都能验证，但没有人能否认。

真实的安全文档工作流两者都用：文档先签名保证真实性，再包进信封保证机密性。只签名不加密的文档，任何截获者都能读到；只加密不签名的信封，任何持有正确公钥的人都能伪造来源。两者是互补关系，不是竞争关系。

每一次 HTTPS 会话都使用混合密钥交换：浏览器和服务器协商一个对称会话密钥，再用非对称密码学保护握手过程。你的银行会话、当前页面、所有走 TLS 的 API 调用，都依赖信封模式。

S/MIME（企业邮件加密）和 PGP/GPG 都用会话密钥加密邮件内容，再用收件人的公钥包裹这个密钥——这就是邮件形态的数字信封。

AWS KMS、Google Cloud KMS、Azure Key Vault 等云平台用信封加密保护静态数据：数据用 DEK 加密，DEK 由客户主密钥（KEK）包裹。这样企业轮换主密钥时无需重新加密存量数据。

电子签名平台存储已签文档和证据包。静态信封加密（DEK/KEK）确保即使存储被攻破，没有密钥管理层，文档和审计轨迹依然不可读。

信封不能证明是谁发的。用某人的公钥加密，只能证明内容只有他能读，但任何人都可能创建这个信封。要证明发送者身份，需要搭配数字签名。

加密保护传输中和静态的内容，但本身不检测篡改。如果你需要证明文档签名后未被改动，要在信封之外使用数字签名或签名哈希（MAC）。

信封的强度取决于周围私钥管理的强度。被盗的私钥能打开发给该收件人的所有信封；丢失的密钥意味着数据永远无法恢复。硬件安全模块（HSM）和密钥托管策略正是为管理这些风险而存在。

确认平台使用哪些密码套件和密钥长度（例如 AES-256 + RSA-3072 或 ECC P-256）。回避不公开密码学标准的厂商。

加密本身不能证明谁签了文档。要获得法律可执行性，需要带证书链的数字签名，外加用于长期有效性的可信时间戳。

检查密钥如何存储和轮换：HSM 托管密钥、租户级密钥隔离、有文档记录的轮换计划，是成熟平台的标志。问清楚主密钥在谁手里——你还是厂商。

对于受监管文档（GDPR、HIPAA、欧盟 eIDAS），确认加密和证据包设计符合相应标准，并且厂商能为你的合规团队提供文档说明。