用於發布/訂閱的離線認證加密
要求：
- 只有發布者可以創建消息
- 發布者和訂閱者都可以讀取消息並驗證發布者
- 離線消息傳輸
- 非參與者無法閱讀消息
- 訂閱者可以是移動平台（Android、iPhone），即功能較弱的處理器
- 消息壽命目標是 15 年
- 消息很小，只有幾十個字節
我正在使用 ECDSA 查看 ECIES，但我似乎無法找到使用 ECIES 的參考，其中發送方擁有靜態密鑰而接收方使用臨時密鑰。https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme#Informal_description似乎很典型，但在我的場景中，Alice 想要發送一條消息，讓 Bob 和他的任何一個朋友閱讀它並知道它來自她。
我知道 RSA 可以通過使用私鑰加密消息特定密鑰並使用公鑰解密來做到這一點（在這裡揮手交出一些細節），但完全相同的結構似乎不適用於 EC。是否存在具有相似特性的 EC 結構？我不希望移動設備不得不遭受 4k RSA 密鑰（以使它們有望在 2030 年代安全）。
您需要對您的消息進行簽名，然後對其進行加密（簽名後加密）。使用來自發布者（發送者）的私鑰執行簽名生成，並使用來自訂閱者（接收者）的公鑰執行加密。解密使用接收方的私鑰執行，簽名驗證使用發送方的公鑰執行。私鑰保持私有，公鑰需要被信任。
只有發布者可以創建消息
任何人都可以創建消息，畢竟它們只是字節。只有發布者才能創建訂閱者接受的消息。
發布者和訂閱者都可以讀取消息並驗證發布者
不僅為訂閱者加密，還為發布者加密，你應該沒問題。
離線消息傳輸
當然可以，但請注意，您可能仍然遇到傳輸協議的所有問題。例如，如果您使用 CBC 模式進行加密，您可能容易受到填充預言機攻擊。
非參與者無法閱讀消息
只有訂閱者（接收者）和發布者才會擁有相應的私鑰，所以是的。
訂閱者可以是移動平台（Android、iPhone），即功能較弱的處理器
對於功率相對較低的設備來說，這兩種方案都不會有問題（如果您可以將最新的智能手機集稱為“低功率”，具有 64 位操作、硬體加密加速器和超過 2 GHz 時鐘速度的高端和中端型號）。
消息壽命目標是 15 年
15 年對加密貨幣來說是一段很長很長的時間。但是，如果您使用 512 / 512 位曲線和 256 位對稱加密（例如 256 位 AES），那麼您的消息應該在很長一段時間內都是安全的，除非使用量子計算的密碼分析大規模起飛。
消息很小，只有幾十個字節
512 位的 ECDSA 簽名至少需要 128 字節，而臨時公鑰（ECIES 需要）大約需要 64 字節。幾十個字節似乎是非常小的可用消息空間。
我知道 RSA 可以通過使用私鑰加密消息特定密鑰並使用公鑰解密來做到這一點（在這裡揮手交出一些細節）
不，它不能。公鑰應該被認為是公開的。
如果您不提前知道所有訂閱者是誰，那麼即使您可以容忍消息的擴展以包含簽名和臨時公鑰，簡單的公鑰加密也不會很好地工作。即使您知道未來 15 年可能需要訪問的所有訂戶，但其中有很多，這也不是很好。如果您不想與所有人共享相同的私鑰，則必須將消息加密到每個訂閱者的公鑰，隨著訂閱者數量的增加，這將很難擴展。
另一種方法是使用代理重新加密方案。代理重新加密 (PRE) 旨在允許公鑰/私鑰對的持有者將解密以她的公鑰加密的消息的能力委託給其他人，而無需向其他人提供她的私鑰。如果您有 PRE 方案，您可以創建一個表示主題/消息隊列的密鑰對，並且發布者可以將每條消息加密為該公鑰。然後獨立於此，您可以將這些消息的訪問權限委託給每個訂閱者（創建從主題密鑰到訂閱者密鑰的重新加密密鑰）。
這種方案的一個好處是，如果有人訂閱了該主題，然後又取消訂閱，則該訂閱者無法解密發佈到該主題的任何新消息。一個缺點是相當多的 PRE 算法使用基於配對的加密，這是相當 CPU 密集型的。
可在此處獲得一篇描述基於 PRE 的支持此案例的系統的論文。免責聲明 - 我是論文的作者，也是一家公司的首席技術官，該公司正在根據該計劃建構產品。但是該論文描述了案例，PRE 如何解決它們，介紹了算法，並在參考書目中包含了對 PRE 中有趣的先前作品的參考。很抱歉引導您瀏覽我們的網站，但如果您無法訪問 ACM 數字圖書館，您可以訪問它。