減輕端到端加密系統中伺服器妥協的影響
我正在開發一個端到端加密的聊天系統，但我遇到了問題。如您所知，在端到端加密聊天中，伺服器根本不受信任。這就是我們進行指紋檢查等的原因。
當我考慮群聊時，問題就出現了。如果 Alice、Bob 和 Eve 正在通信，並且 Jill 決定加入伺服器，我們將不得不為她重新進行密鑰交換。但是，如果 Jill 是惡意攻擊者怎麼辦？我們會給她加密密鑰！我想到的解決方案是將每個
"trustworthy"客戶端的公鑰放在伺服器上的一個文件中，就像 SSH 一樣，然後客戶端可以在連接時使用數字簽名來標識自己。現在，正如 DW 指出的那樣，這需要信任伺服器，這違反了標準的端到端規範。事實上，任何允許伺服器選擇誰在聊天中的解決方案都需要對伺服器的信任。因為如果伺服器受到威脅或不誠實，而不是嘗試 MITM 攻擊，它決定將自己的公鑰添加到 authorised_keys 文件中怎麼辦？然後他可以以合法使用者身份連接並竊取會話密鑰。（這就是 SSH 的做法，我不確定它如何減輕這種可能性，所以作為一個附帶問題，清除它會有所幫助。）
在端到端的加密系統中，伺服器通常有什麼程度的控制？我的意思是 Signal Messenger 必須考慮過這種情況並加以緩解。
讓我這樣提出我的問題：確定誰是端到端加密群聊的一部分的推薦做法是什麼？通過推薦的實踐，我的意思是傳達一個從眾所周知且受信任的協議或事物（如信號協議）中提取的答案將是最佳的。要求是伺服器不應受信任，並且客戶端的機密性和安全性應在對抗模型中保持不變。如果伺服器受到威脅，他們也應該堅持下去。
顯然，如果伺服器無法決定誰在組中，那麼客戶端將不得不以某種方式授權每個額外的成員，但要無縫。我該如何處理？這個想法是伺服器始終處於啟動狀態，客戶端可以隨時加入和斷開連接，就像聊天室一樣。
可信伺服器
這是正確的。使用受信任的伺服器處理組密鑰管理有幾種標準方法：
- **組密鑰：**使用組中每個人都知道的單個組密鑰。每當有人從組中刪除時，更改組密鑰並更新應該仍然具有訪問權限的每個人。使用對稱密鑰作為組密鑰；這使得加密和解密高效。
- 個人密鑰，帶有伺服器代理：為每個人提供他們自己的個人對稱密鑰，該密鑰僅與伺服器共享。每個人都與伺服器建立了安全連接，使用此密鑰進行保護，伺服器轉發消息（解密和重新加密）。這是一個中心輻射型模型，伺服器負責確定允許誰查看消息。當有人從群組中刪除時，伺服器將停止向他們轉發消息。
- **組成員簽名列表：**讓伺服器簽署組成員列表以及時間戳。例如，每個組成員可以由其公鑰指示。重要的是要為伺服器提供一種方法來證明簽名列表的新鮮度（例如，在簽名數據中包含時間戳）。該解決方案與您在問題中勾勒的內容大致相似，只是您似乎忽略了對時間戳和簽名的需求。客戶端必須定期輪詢伺服器以檢查組成員列表的更新。
如果您使用公鑰加密來加密組成員之間的所有消息，這將不必要地昂貴/緩慢，因為它需要所有客戶端使用公鑰加密來加密每條消息，並且需要 $ O(n) $ 每條發送的消息的公鑰加密。但是，每個客戶端可以與組中的每個其他授權成員交換對稱密鑰（使用伺服器提供的公鑰），記憶體此對稱密鑰，並將其用於所有後續消息，這樣會更有效率。
是的，這是一種痛苦，但這是一種必要的痛苦。
不，由於您提到的原因，您的解決方案不安全：因為組成員列表未簽名，所以可以由中間人修改。
所有這些解決方案都需要對伺服器的信任。這是不可避免的：伺服器確定誰被授權加入組是您的問題規範的一部分。因此，惡意伺服器可以將自己添加到組中並讀取/修改所有流量。一旦你從一個伺服器有權決定組成員身份的世界開始，你必須信任伺服器。 沒有辦法避免信任伺服器，如果伺服器有權決定誰是組的一部分——在該模型中，沒有辦法建構一個不涉及對伺服器的信任的解決方案。
不受信任的伺服器
最簡單的方法是讓一個組長負責組成員，並完全控制組中的人員列表。最自然的模型是組長是第一個創建組的人——因此組所有者是組的成員之一，並控制其他成員是誰。
您可以輕鬆地支持該模型，而無需信任伺服器。只需採取上述三個解決方案中的任何一個，但將“伺服器”替換為“組所有者的機器”。
還有其他可以想像的方法——例如，一旦有人在組中，他們就永遠不會被刪除（撤銷是不可能的）；或者，所有成員都必須批准每個小組成員，並且任何成員都可以隨時將任何人踢出小組——但是這些的可用性後果看起來很可怕，所以我無法想像它們會變得有吸引力。