需要一個“主管”密鑰對和一個“使用者”密鑰對來解密多個收件人的消息
我最近一直在玩弄一些加密場景。我遇到的困難之一是多方系統。
所以我們有
- Bob – 發送消息的人（並且知道它的接收者）
- Jim – 能夠解密消息的監督人（但不能自己解密消息）
- Alice – 想要接收消息的人
- Mark – 也想接收消息的人，但在 Bob 發送消息後，他的私鑰被洩露
例如，Bob 必須在公共留言板上發布他的加密消息。理想情況下，Alice 和 Mark 會看到該消息並知道它是給他們的，但他們不能自己解密它。他們必須首先要求 Jim 將他的解密技巧應用於公共數據。Jim 信任請求消息的人，因為他知道他們的公鑰（並要求提供動態簽名的數據或類似內容）。當然，Jim 不會對 Mark 施展魔法，因為他被告知 Mark 已被入侵。所以，馬克被留在了黑暗中，留下了一個無法辨認的資訊
此外，Jim 的可信度最低。因此，如果 Jim 想將消息交給某個不受信任的一方，它仍然是毫無用處的，除非他們自己也知道其中一個預期接收者的私鑰。
我正在嘗試找出真正做到這一點的最佳方法。這是一個想法：
- Bob 使用對稱算法加密他的消息。
- Bob 使用他的私鑰對 Alice 和 Mark 的公鑰加密對稱密鑰（因此產生了兩個單獨的“密鑰消息”）
- 最後，Bob 使用他的私鑰針對 Jim 的公鑰加密了兩個密鑰消息
我認為這會奏效。不過，我有一些顧慮
- 我正在對事物進行雙重加密，這聽起來很麻煩
- 我必須針對兩個不同的密鑰加密基本上相同的數據。這會讓我容易受到密碼分析嗎？填充呢？
理想情況下，首先想到的對稱加密算法是 AES。對於非對稱加密，我在考慮 RSA。有更好的選擇嗎？
有沒有更好的方法來管理這樣一種情況，即您有一個“主管”來減輕發送給多個收件人的消息的私鑰洩露風險？
您是否考慮過使用Shamir 的秘密共享算法？
首先，Bob 使用對稱算法加密消息。然後，他使用 SSA 將密鑰分成四個部分，這樣它需要三個部分來解密（a $ (3,4) $ 臨界點）。然後 Bob 將一份分配給 Alice 和 Mark，兩份分配給 Jim。
當 Alice 想要解密時，她需要同時擁有 Jim 的部分和她的部分。如果 Mark 想要解密，他同樣需要 Jim 的部分和他的部分。
愛麗絲和馬克不能串通把吉姆從中間切開，因為他們之間只有兩部分，解密需要三部分。而且由於吉姆自己只有兩部分，他無法解密消息，除非愛麗絲或馬克與他分享他們的部分。
最後，吉姆可以對他不再信任的任何人隱瞞他的部分。
我經常描述一些過程，說“他”對“他的”資訊做了一些事情，這在我自己的腦海中是有道理的，但沒有人能弄清楚這些代名詞所指的涉及的幾個人中的哪一個。或者更糟——有時我會說“消息是加密的”，但我沒有說是誰做的以及使用哪個密鑰。
這就是為什麼所有優秀的密碼學家都使用Alice 和 Bob來描述過程，避免使用代名詞——即使他們必須在一個句子中使用“Bob”六次。
您是否考慮過用名稱替換所有代名詞來編輯您的問題？這將使我們更容易弄清楚你想問什麼。
讓我也添加夏娃：
- 夏娃偷走了馬克的私鑰。
- Bob 想向 Alice 和 Mark 發送一條消息，但 Bob 不希望其他人看到它——尤其是 Bob 不希望 Jim 或 Eve 看到它。但是，Bob 希望 Jim 能夠阻止 Eve 閱讀該消息，即使這意味著 Mark 根本無法閱讀該消息。另外：Bob 在一個偏遠的地方，Bob 發送的每條消息都必須通過像 Eve 這樣的人可以閱讀的公共網路。
- 馬克想收到消息，但在鮑勃發送消息後，馬克發現夏娃偷走了馬克的私鑰，馬克立即通知了吉姆。
- Jim 相當可靠，但他在另一個偏遠的地方，Jim 發送或接收的每條消息都必須通過像 Eve 這樣的人可以閱讀的公共網路。
John Deters 描述的 SSS 系統聽起來不錯。另一種方法（類似於 TOR 洋蔥路由系統）可能是：
- 假設 Bob、Jim、Mark 和 Alice 之前已經與組中的其他人握手並交換了公鑰。
- Bob 向 Jim 發送消息 M1，向 Mark 和 Alice 發送 M6。
- Bob 發送消息後的某個時間，Eve 竊取了 Mark 的私鑰。
- 在收到 Bob 的消息之前，Jim 不知何故得知了這個關鍵的妥協。
- Jim 驗證消息 M1 確實來自 Bob，然後使用 Jim 的私鑰對其進行解密，從而得到部分解密的消息 M2，上面寫著“請將此消息轉發給 Mark：”，然後是加密消息 M3 和“請轉發此消息”。給 Alice 的消息：" 後跟加密消息 M4。
- 由於 Jim 無法再向 Mark 發送任何內容（因為如果他這樣做了，Eve 也將能夠閱讀該消息），他撕碎了 M3。
- （可選）Jim 驗證 M4 確實來自 Bob。
- Jim 將 M4 原封不動地發送給 Alice。
- （如果 Jim 在他發送消息 M4 後得知 Alice 的密鑰被洩露，那就太晚了——任何人都無法阻止竊取 Alice 密鑰的人恢復明文消息）。
- Alice 驗證 M4 確實來自 Bob，然後用 Alice 的私鑰對其進行解密，從而生成明文消息 M5。
- （可選）也許 M5 實際上是一個對稱密鑰。Bob 使用密鑰 M5 對原始長明文消息進行加密，然後對生成的密文進行簽名，將生成的簽名消息 M6 直接發送給 Alice 和 Mark。一旦 Alice 驗證 M6 確實來自 Bob，Alice 使用 M5 解密 M6 並恢復原始的長明文消息。
即使在 Eve 收集了所有的公共消息 M1、M4 和 M6 之後，Eve 仍然無法恢復原始長明文消息，除非 Jim 與 Eve 勾結洩露 M3，或者 Alice 與 Eve 勾結洩露 M5 或原始長明文消息或 Alice 的私鑰。
- 雙重加密，聽起來很麻煩
- 針對兩個不同的密鑰加密基本上相同的數據
假設您使用的是現代加密系統，這兩者在實踐中都不是真正的問題。
生成許多加密消息，每個消息都是相同數據的單獨加密密文，但使用不同的公鑰加密，是生成用於多個收件人的標準OpenPGP加密文件的標準方法的關鍵部分。（它實際上會生成許多短的加密“數據包”，每個都用不同的公鑰加密，但它們都代表相同的對稱密鑰）。
用一個密鑰加密一些明文，然後用另一個密鑰加密得到的密文，然後用另一個密鑰加密得到的密文，這是TOR 匿名網路中的常見操作。
這兩種方法都存在很多混淆 - 請參閱https://crypto.stackexchange.com/search?q=double+encryption。
從歷史上看，一些經典的加密算法在其中一種或一些類似的設置上存在問題。尤其是臭名昭著的“兩次墊”。
然而，現代算法通常使用一種操作模式，使此類攻擊與完全暴力攻擊一樣困難——即不可行。
填充呢？
我假設您正在使用對稱密鑰加密的現成高級實現——例如，幾乎任何支持AES 加密的“.zip”文件的程序。我假設您正在使用現成的高級公鑰加密實現——例如，幾乎任何支持標準 OpenPGP 格式的程序。
預設情況下，該軟體應自動使用良好的操作模式——該軟體應生成初始化向量、處理填充等，而無需您付出額外的努力。如果沒有，我建議切換到其他更易於使用的程式碼庫。