如果我們最終需要對稱密鑰，代理重新加密有多大用處？
我正在嘗試設計一個使用代理重新加密（PRE）的系統，以允許使用者（委託人）和他委託訪問的其他使用者（委託人）之間共享數據。目標是使用 PRE 方案來防止共享委託人的私鑰。
我想要一個所有數據都加密的數據庫，每個委託人的數據都在他的私鑰下加密。如果有人請求訪問委託人的數據，有 2 個選項：
- 具有合法的訪問權限，在這種情況下應返回數據；
- 無權訪問請求的內容，不應返回數據；
代理將有一個重新加密密鑰，而受委託者將有另一個密鑰將代理的（部分解密的）密文轉換為明文。
我的問題：如果我的記錄在我的對稱密鑰下加密，並且我允許受託人查看該密鑰（在代理部分解密該密鑰後，受託人的定義將意味著他是可以完成解密的人），那麼他就可以訪問到所有委託人文件。
我在想一個解決方案可能是讓每條記錄在不同的密鑰下加密，因此受託人只能訪問加密他請求的文件的密鑰。這似乎會有瘋狂的計算/儲存成本。
另一種選擇是對 DB 進行某種代理，它可以在將數據發送給有效的受託人之前動態生成密鑰並加密數據。這裡的問題是該數據在數據庫中被加密，因此代理必須能夠在使用這個新密鑰再次加密之前對其進行解密。這意味著代理必須知道密鑰，從而破壞了 PRE 方案的全部要點（此外，委託人將不知道加密自己文件的密鑰，這是不可取的）。
最後，我在這裡發布這個的原因是因為我相信這與對 PRE 方案的理解以及如何在實踐中使用它們有關。
我們來看一個代理重加密的例子：
- 使用者A用他們自己的公鑰加密一個特定的數字（即消息），生成ct。
- 使用者A將ct發送到代理。
- 使用者A確定使用者B和C應該能夠解密ct並使用他們的公鑰和A的秘密密鑰來生成兩個重新加密的密鑰，然後發送到代理。代理沒有任何可用於解密ct和恢復號碼的密鑰。
- 使用者B和C可以針對將使用相應的重新加密密鑰生成最終ct的代理來辨識自己 $ _B $ 或ct $ _C $ . 代理必須儲存所有三個版本的密文（原始 + 兩個重新加密的版本）。請求的使用者只得到他們對應的密文。
- 使用者B和C可以使用他們的密鑰來解密他們對應的密文。
可以加密消息有一個大小限制，因為 ElGamal 樣式的方案在循環組中工作，只允許特定大小的元素（數字）。
如果我們想加密更大的消息，我們需要使用某種策略將整個大消息包裝在一個額外的安全層中。這可以是對稱加密。與非對稱加密相結合稱為混合加密。
- 使用者A生成一個隨機 AES 密鑰，並在該 AES 密鑰下使用 AES 加密大消息，生成對稱密文ct $ _s $ . 然後將 AES 密鑰轉換為一個數字並在他們自己的公鑰下加密，生成非對稱密文ct $ _a $ .
- 使用者A發送ct $ _s $ 和ct $ _a $ 到代理。
- 使用者A確定使用者B和C應該能夠解密ct並使用他們的公鑰和A的秘密密鑰來生成兩個重新加密的密鑰，然後發送到代理。代理沒有任何可用於解密ct的密鑰 $ _s $ 或ct $ _a $ 並恢復號碼或原始消息。
- 使用者B和C可以針對將使用相應的重新加密密鑰生成最終ct的代理來辨識自己 $ _{a,B} $ 或ct $ _{a,C} $ . 代理必須儲存所有三個版本的非對稱密文（原始 + 兩個重新加密的版本），並且只儲存一個版本的對稱密文。每個請求使用者都會收到對稱密文及其對應的非對稱密文。例如，使用者B收到ct $ _{a,B} $ 和ct $ _s $ .
- 使用者B和C可以使用他們的密鑰來解密他們對應的非對稱密文，然後使用恢復的數字將它們轉換為 AES 密鑰並解密對稱密文。
當消息變大時，只有非對稱密文需要為每個額外的使用者進行額外的處理和儲存。根據使用的原語，非對稱密文通常具有 512 到 4096 位的大小。非重複對稱密文的大小與原始消息的大小幾乎相同（僅相差一個常數，例如對於具有 sensible 模式的 AES，最多為 256 位）。
關鍵部分是，如果收件人可能不同，使用者A必須為他們想要發送的每條消息生成一個新的隨機 AES 密鑰。但是這種密鑰包裝方法可用於進一步刪除多條消息，因為它們總是要被同一組使用者接收。然後使用者A必須為每組使用者分配一個唯一且隨機的 AES 密鑰（不會離開使用者A的系統）。