什麼是加密密封？

在修改我的 CAdES 庫時，我在數字簽名中遇到了一些“密封問題”。

Win SDKsigntool.exe有一個/seal參數，它在簽名“Intent to Seal”中生成 1 個經過身份驗證的屬性，在簽名文件中生成一個未經身份驗證的屬性“Sealing Signature”。

我也在 PDF 文件中看到了這一點。在網上找不到更多關於它的資訊。

我的問題是：

1. “密封”與簡單地簽署消息的目的是什麼？
2. 與它們關聯的 OID 是什麼？什麼是相關的 RFC？
3. 只是在 PKCS#7 中添加 2 個屬性，還是我必須考慮另一個問題？
4. 為“密封”消息加時間戳時有區別嗎？

加密密封是應用非對稱加密來加密會話密鑰，使其無法使用——直到決定移除密封並使用該密鑰。這是一種保護機制。請參閱Oracle 的此描述：

密封對稱密鑰涉及創建一個密封對象，該對象使用非對稱密碼來密封（加密）會話密鑰。不能使用 RSA 非對稱算法，因為它具有下一節中描述的大小限制，並且密封過程使會話密鑰太大而無法與 RSA 算法一起使用。

加密密封的想法已經存在了很長時間。1981 年的一篇論文，用於資訊保密和認證的加密密封。，由 David K. Gifford 撰寫，詳細介紹了它：

描述了一種新的保護機制，它提供了用於保護和認證的通用原語。該機制基於用鑰匙密封物體的想法。密封對像是自我認證的，並且在沒有適當的密鑰集的情況下，僅提供有關其內容大小的資訊。可以隨時自由創建新的密鑰，也可以通過Key-And和Key-Or等操作符從現有的密鑰中派生出密鑰。這種靈活性允許保護機制實現通用的保護機制，例如能力、訪問控制列表和資訊流控制。該機制是通過綜合傳統密碼學、公鑰密碼學和門檻值方案來實施的。

所以，蓋章的目的和簽字的目的是有很大區別的。密封防止使用會話密鑰。我一直找不到任何處理密封的 RFC。我也沒有找到任何適用的 OID。據我所知，就加密過程而言，密封中涉及的時間戳將與正常情況相同。RFC 5652（加密消息語法）沒有特別提到加密密封。

對於一些非常簡單的事情，似乎有很多官僚主義的說法。

這種所謂的密封與 NaCl 的 seal_boxes 相同，即使意圖似乎不同。相同的算法。所以你可以在那裡尋找實現。

您基本上執行了一次短暫的“握手”（Diffie-Hellman）並隨後刪除了短暫的私鑰，從而破壞了與剛剛發生的握手有關的密鑰資訊。如果握手的結果被用作某些數據的對稱密碼，則該數據現在由一個沒人知道的密鑰加密，並且只有在握手中擁有另一方私鑰的人才能重新創建它——只要他是給定生成並附加到現在加密數據的臨時公鑰。

它與普通簽名的不同之處在於保密，消息本身只能由預期的收件人閱讀。如果需要，可以另外進行簽名。

對於現實世界的使用範例，有勒索軟體。他們加密您的文件並密封加密密鑰。在您向他們付款並給他們密封的密鑰後，他們會為您（或他們的軟體）提供未密封的密鑰，然後解密您的文件。對惡意軟體進行逆向工程不會讓您獲得用於加密文件的密鑰，因為它已被破壞。

引用自：https://crypto.stackexchange.com/questions/72231