libsodium中的密封盒和普通盒有什麼區別？
我正在嘗試學習 libsodium 以提高我的加密知識。我有一個煩人的問題是 libsodium 的密封盒和普通盒子有什麼區別？不是在技術方面，因為文件確實很好地區分了這一點；但就實際案例而言。
根據文件：
密封箱旨在根據其公鑰匿名向收件人發送消息。
只有接收者可以使用其私鑰解密這些消息。雖然收件人可以驗證消息的完整性，但它無法驗證發件人的身份。
使用臨時密鑰對對消息進行加密，其秘密部分在加密過程後立即被破壞。
在不知道給定消息使用的密鑰的情況下，發送者以後無法解密自己的消息。如果沒有額外的數據，消息就無法與其發送者的身份相關聯。
遺憾的是，這並沒有解決需要時的案例。例如，假設 Alice 生成一個密鑰對，並給不可信的第三者 Charlie 用於儲存的公鑰。Bob 向 Charlie 索要公鑰，並使用該公鑰向 Alice 發送一條消息。根據我對此的有限理解，這應該是安全的，並且可以防止查理知道該消息。這不是與 PGP 相同的基本端到端信任無人系統嗎？
如果按照密封盒概念所建議的那樣，使用臨時密鑰交換來實施該系統，那不僅會給已經安全的系統增加更多成本嗎？
也許我誤解了，也許我的預期案例不同，這就是為什麼我將解釋我的心智模型以更好地提供上下文。（另請注意，我認為信號協議使用臨時預密鑰，我也不明白為什麼在這種情況下）。
Alice 在她的手機上執行一個應用程序，該應用程序生成一個唯一的密鑰對（獨特之處在於它每次打開應用程序時都會重新生成一個新的密鑰對），然後向後端伺服器 Charlie 註冊一個唯一的地址以及她的公鑰。然後，該應用程序向 Alice 提供一個包含她的唯一地址和 nonce 的 URL。她與 Bob 分享了這個連結，Bob 也打開了應用程序，提供了地址和隨機數。Bob 的應用程序生成一個唯一的密鑰對，然後向 Charlie 詢問 Alice 的公鑰（基於地址）。Bob 的應用程序隨後將 Bob 的公鑰與 nonce 一起加密，並將其發送給 Alice（通過 Charlie）。Alice 的應用程序驗證隨機數，然後使用提供的 Bob 的公鑰，現在可以將消息發回給他。
AFAICT 以上是通過第三方進行的非常基本的密鑰交換，與我們在密鑰伺服器上處理 PGP 密鑰共享的方式相同，其明顯區別在於，一旦會話結束（應用程序關閉），密鑰不再有效（秘密密鑰被刪除），新的會話將是全新的身份和密鑰對。
這甚至與使用密封盒子有很大關係，還是我只是證明我睡眠不足並且對加密一無所知？
盒子的前提是愛麗絲和鮑勃彼此認識並互相寫信。Alice 可以使用一個盒子向 Bob 發送消息。收到盒子後，Bob 知道 (a) 它來自 Alice，並且 (b) 沒有其他人可以閱讀或篡改它。
密封箱的前提是Bob 有一個匿名保管箱。Alice 可以使用一個密封的盒子向 Bob 發送消息。收到盒子後，Bob 不知道除了發件人可能已經閱讀或篡改它之外的任何人。但他對發件人是誰一無所知——可能是愛麗絲、查理或多米尼克。
只需要Alice 發送給 Bob 的每條消息的 nonce 都是不同的，反之亦然。例如，Alice 可能會計算她迄今為止發送的消息數量，並將該數字用作隨機數。如果 nonce 足夠大，比如≥192，就像在 crypto_box_curve25519xsalsa20poly1305 中一樣（但不是crypto_box_nistp256aes256gcm，它是 96），則可以安全地為每條消息隨機均勻地選擇它並附加到密文中。 隨機數不必是秘密的。
盒子和密封盒子都不能讓第三方驗證消息的真實性。為此，您需要數字簽名。
如果 Bob 的私鑰被洩露，無論是對於盒子還是密封盒子，或者如果 Alice 的盒子私鑰被洩露，那麼 Alice 發送給 Bob 的任何消息都可以被解密。為避免這種情況，Signal (a) 等協議會定期生成新密鑰並及時刪除box、*和 (b) 等協議的長期密鑰對，僅用於數字簽名以斷言使用者目前的 box 公鑰是什麼，因此損害長期私鑰不會啟用追溯解密。
規定何時及時擦除密鑰的協議有時被稱為“前向保密”，我更願意避免使用這個術語，因為它的流利性掩蓋了何時*可以擦除密鑰——這種模糊性可能有助於隱藏潛伏的漏洞，如 TLS 會話即使在使用帶有臨時 Diffie-Hellman 密鑰協議的“前向保密”密碼套件的會話中也可以恢復。