Public-Key
具有對稱 + 公鑰加密、TLS 和證書固定的端到端加密聊天應用程序
端到端加密消息服務的一大缺點是，一旦您失去設備，您就會失去所有消息。畢竟你的私鑰已經不見了。不過我想知道，是否可以在 iOS 的聊天應用程序中執行以下操作，使用證書固定和 TLS 與伺服器進行所有通信：
- 一旦使用者登錄應用程序，就會生成一個非對稱密鑰對並儲存在本地，並將公鑰發送到數據庫；
- 當使用者 X 開始與使用者 Y 聊天時，X 的設備生成一個對稱加密密鑰，將其儲存在本地，使用 Y 的公鑰（從中央數據庫下載）對其進行加密，並將密文發送到數據庫；
- Y 的設備一上線，就會下載密文，使用其私鑰對其進行解密，並將其儲存在本地。
現在，X 和 Y 都擁有 X 的設備生成的密鑰，並且可以使用對稱加密相互發送消息，當然，除了 X 和 Y 之外，沒有人擁有對稱加密密鑰。比如說，當 X 拿到一部新手機時，會發生以下情況：
- X 登錄新設備並將新的公鑰發送到數據庫。
- Y 的設備會注意到上傳了一個新的公鑰，下載此密鑰，用 X 的新公鑰加密對稱加密密鑰（它在步驟 3 中收到），並將密文發送到數據庫。
- X 的設備下載密文，使用其私鑰對其進行解密，現在可以下載所有舊消息並對其進行解密。
所以，我想我的問題是：我錯過了什麼讓我的設計不安全？將密鑰長時間儲存在數據庫中是不是很聰明，即使它們是用強非對稱加密加密的（比如 8192 位，只是為了好玩）？
另外，我是一名 iOS 開發人員，所有的密鑰都會儲存在 iOS 鑰匙串中，這是一種非常安全的本地儲存資訊的方式。我知道，沒有什麼是 100% 安全的，但據我所知，在 iOS 上儲存東西幾乎是最好的。
一個問題是伺服器完全控制身份驗證和信任，並且很容易聲稱 X 有一個新的密鑰對，導致 Y 為伺服器控制的密鑰加密對稱密鑰。因此，至少對於某些攻擊場景，您實際上缺乏端到端加密。
另一個問題是使用長期對稱密鑰直接加密消息意味著沒有前向保密。如果對稱密鑰在任何時候被洩露，雙方之間的所有通信都可以被解密，即使是那些很久以前發生的通信。