信封保护
一句话讲清区别
数字信封让文档保持机密(机密性),数字签名则证明是谁签的、文档有没有被改动(真实性与完整性)。两者经常被混淆,因为它们都使用公钥密码学,但它们回答的是不同的安全问题——而严肃的文档工作流会两者并用。
签名证明
信封使用
签名使用
法律效力
两种机制并排对照
两者都是建立在密钥对之上的密码学工具,但各自回答关于文档的不同问题。
回答的问题:「还有别人能读到吗?」发送方用随机对称密钥(DEK)加密文档,再用收件人的公钥(KEK)加密这个密钥。只有收件人的私钥能解出 DEK 并读取内容。
回答的问题:「这真的来自这个人吗?有没有被改动?」签名者计算文档哈希并用私钥加密。任何持有签名者公钥的人都能验证哈希是否匹配——从而证明身份并检测篡改。
信封用收件人的密钥打开,签名用签名者的密钥验证。这种不对称正是为什么信封对除收件人以外的所有人隐藏内容,而签名则能被任何信任签名者证书的人验证。
信封加密通常采用混合加密(AES + RSA/ECC),不产生法律意义上的签名。数字签名使用 PKI 证书,是法院和法规(eIDAS、ESIGN、UETA)认可的签名形式。
四种组合,四种结果
理解这两个工具最清晰的方式,是看它们各自组合之后能达到什么效果。
只签名(无信封)
文档可能被任何人截获并阅读——但它带有发送者证明,被改动就会被发现。这是公开合同、公告或公开发布的签名 PDF。不要求机密性,要求来源可证。
只加信封(无签名)
文档对外人不可读,但没有任何东西能证明是谁创建的。任何持有收件人公钥的人都可以发出它。适用场景狭窄:发送者已通过其他方式认证的安全通道。
两者并用(信封 + 签名)
文档既保密又可证明真实:密封到只有指定收件人能读,签名到收件人能验证发送者并检测任何篡改。这是合同、NDA、财务文件和法律文书的黄金标准。
两者都不用
机密性和真实性都没有保护。只适合公开、非敏感、既不需要保密也不需要证明的文档。
为什么人们容易混淆
这种混淆可以理解——两者都涉及公钥、证书和密码学。三种模式解释了大多的误认。
同一工具箱,不同的锁
两个工具都用密钥对,都被称为「数字」保护。当产品说「已加密且已签名」时,用户往往分不清哪部分是哪个——加密对应信封,签名对应签名。
产品用语模糊了界限
厂商有时用「密封」描述一个既签名又加密的文档,或用「信封」描述签名流程(如「发送一个信封」)。这些产品术语模糊了密码学上的区分。
编辑锁定感觉像密封
在很多产品中,签署文档也会锁定它防止进一步编辑,这感觉像「密封」。但编辑锁定是工作流功能,不是加密——拿到副本的人仍然可能读到文档。
法律效力:法庭上看哪个?
当文档进入纠纷时,法律审查的是签名——而不是信封。
法律认可的是签名
美国 ESIGN 法案、UETA 和欧盟 eIDAS 法规都以签名来定义法律效力:签名者的意图、身份和同意。没有签名的加密文件,没有可追责的签名者。
数字签名有证据分量
由合格证书支撑的数字签名(eIDAS 下的 QES)具有最强的证据分量——真实性和完整性的推定。信封不提供任何此类推定;它只能证明内容被某个特定密钥持有者读取过。
信封是支撑,不是替代
加密在诉讼中仍然重要:它表明你采取了合理措施保护敏感数据(在 GDPR 和数据泄露索赔中相关),并防止文档在案件开始前泄露。它是支撑层,不是法律核心。
关于两者的常见问题
两者都是使用密钥对的密码学构造,但目的不同:信封加密内容以保护机密性(用收件人的公钥),签名认证发送者并检测篡改(用签名者的私钥)。
eSign.AI 如何两者并用
eSign.AI 通过传输加密(TLS)和静态信封加密(托管密钥)保护文档,并把机密性层与基于 PKI 的数字签名、可信时间戳和完整证据包配对——让每份已签文档既被密封,又具有法律可证明性。
快速决策清单
发送前,用这个清单判断文档需要什么。
内容敏感?→ 用信封
如果内容必须对除收件人以外的所有人保密,需要加密(数字信封)。如果不要求保密,可以省去。
需要来源证明?→ 用签名
如果必须证明是谁发的、有没有被改动,需要数字签名。合同、审批和合规申报都属于此类。
既敏感又有法律意义?→ 两者都用
对合同、NDA、医疗记录和财务文档——既敏感又有法律意义——两者都用。先签名,再加密。
核实平台两者都做
确认你的电子签名平台对两层都有文档说明:加密的密码套件与密钥保管,签名的证书链与时间戳。如果没有公开,要求书面提供。







