什麼是數字信封？信封加密解析

對稱加密（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），確認加密和證據包設計符合相應標準，並且廠商能為你的合規團隊提供文檔説明。