信封保護
一句話講清區別
數字信封讓文檔保持機密(機密性),數字簽名則證明是誰籤的、文檔有沒有被改動(真實性與完整性)。兩者經常被混淆,因為它們都使用公鑰密碼學,但它們回答的是不同的安全問題——而嚴肅的文檔工作流會兩者並用。
簽名證明
信封使用
簽名使用
法律效力
兩種機制並排對照
兩者都是建立在密鑰對之上的密碼學工具,但各自回答關於文檔的不同問題。
回答的問題:「還有別人能讀到嗎?」發送方用隨機對稱密鑰(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、醫療記錄和財務文檔——既敏感又有法律意義——兩者都用。先簽名,再加密。
核實平台兩者都做
確認你的電子簽名平台對兩層都有文檔説明:加密的密碼套件與密鑰保管,簽名的證書鏈與時間戳。如果沒有公開,要求書面提供。







