專業知識庫

數字信封 vs 數字簽名:有什麼區別?

數字信封保護機密性,數字簽名證明真實性與完整性。它們有什麼區別、如何配合使用、什麼時候該用哪個。

eSign.AI Digital Trust Research Team8 分鐘閱讀

一句話講清區別

數字信封讓文檔保持機密(機密性),數字簽名則證明是誰籤的、文檔有沒有被改動(真實性與完整性)。兩者經常被混淆,因為它們都使用公鑰密碼學,但它們回答的是不同的安全問題——而嚴肅的文檔工作流會兩者並用。

機密性

信封保護

真實性

簽名證明

收件人公鑰

信封使用

簽名者私鑰

簽名使用

簽名(非信封)

法律效力

兩種機制並排對照

兩者都是建立在密鑰對之上的密碼學工具,但各自回答關於文檔的不同問題。

01

回答的問題:「還有別人能讀到嗎?」發送方用隨機對稱密鑰(DEK)加密文檔,再用收件人的公鑰(KEK)加密這個密鑰。只有收件人的私鑰能解出 DEK 並讀取內容。

02

回答的問題:「這真的來自這個人嗎?有沒有被改動?」簽名者計算文檔哈希並用私鑰加密。任何持有簽名者公鑰的人都能驗證哈希是否匹配——從而證明身份並檢測篡改。

03

信封用收件人的密鑰打開,簽名用簽名者的密鑰驗證。這種不對稱正是為什麼信封對除收件人以外的所有人隱藏內容,而簽名則能被任何信任簽名者證書的人驗證。

04

信封加密通常採用混合加密(AES + RSA/ECC),不產生法律意義上的簽名。數字簽名使用 PKI 證書,是法院和法規(eIDAS、ESIGN、UETA)認可的簽名形式。

四種組合,四種結果

理解這兩個工具最清晰的方式,是看它們各自組合之後能達到什麼效果。

只簽名(無信封)

文檔可能被任何人截獲並閲讀——但它帶有發送者證明,被改動就會被發現。這是公開合同、公告或公開發布的簽名 PDF。不要求機密性,要求來源可證。

只加信封(無簽名)

文檔對外人不可讀,但沒有任何東西能證明是誰創建的。任何持有收件人公鑰的人都可以發出它。適用場景狹窄:發送者已通過其他方式認證的安全通道。

兩者並用(信封 + 簽名)

文檔既保密又可證明真實:密封到只有指定收件人能讀,簽名到收件人能驗證發送者並檢測任何篡改。這是合同、NDA、財務文件和法律文書的黃金標準。

兩者都不用

機密性和真實性都沒有保護。只適合公開、非敏感、既不需要保密也不需要證明的文檔。

為什麼人們容易混淆

這種混淆可以理解——兩者都涉及公鑰、證書和密碼學。三種模式解釋了大多的誤認。

同一工具箱,不同的鎖

兩個工具都用密鑰對,都被稱為「數字」保護。當產品説「已加密且已簽名」時,用户往往分不清哪部分是哪個——加密對應信封,簽名對應簽名。

產品用語模糊了界限

廠商有時用「密封」描述一個既簽名又加密的文檔,或用「信封」描述簽名流程(如「發送一個信封」)。這些產品術語模糊了密碼學上的區分。

編輯鎖定感覺像密封

在很多產品中,簽署文檔也會鎖定它防止進一步編輯,這感覺像「密封」。但編輯鎖定是工作流功能,不是加密——拿到副本的人仍然可能讀到文檔。

關於兩者的常見問題

兩者都是使用密鑰對的密碼學構造,但目的不同:信封加密內容以保護機密性(用收件人的公鑰),簽名認證發送者並檢測篡改(用簽名者的私鑰)。

eSign.AI 如何兩者並用

eSign.AI 通過傳輸加密(TLS)和靜態信封加密(託管密鑰)保護文檔,並把機密性層與基於 PKI 的數字簽名、可信時間戳和完整證據包配對——讓每份已籤文檔既被密封,又具有法律可證明性。

快速決策清單

發送前,用這個清單判斷文檔需要什麼。

內容敏感?→ 用信封

如果內容必須對除收件人以外的所有人保密,需要加密(數字信封)。如果不要求保密,可以省去。

需要來源證明?→ 用簽名

如果必須證明是誰發的、有沒有被改動,需要數字簽名。合同、審批和合規申報都屬於此類。

既敏感又有法律意義?→ 兩者都用

對合同、NDA、醫療記錄和財務文檔——既敏感又有法律意義——兩者都用。先簽名,再加密。

核實平台兩者都做

確認你的電子簽名平台對兩層都有文檔説明:加密的密碼套件與密鑰保管,簽名的證書鏈與時間戳。如果沒有公開,要求書面提供。

團隊正在討論適合業務的電子簽名方案

為你的業務探索合適的電子簽名方案

與我們的團隊溝通你在目標市場的電子簽名需求、合規考量和文件流程。