採用 AES-256 MODE OFB 的加密設計
我有以下APP設計
密鑰庫（包含 1:n 使用者有效負載作為 1:n 密鑰庫條目）
密鑰儲存鹽（用於將密鑰儲存密碼擴展到 256 位，以明文形式儲存）
密鑰儲存條目（使用者想要加密的內容）：
- 自己的條目 IV（有效負載使用 AES-256 MODE OFB 加密，IV 以明文形式儲存）
- 自己的條目 SALT（加密前隨機附加到有效負載的 64 個字節，SALT 以明文形式儲存）
加密的條目以 base64 編碼儲存：
- 模型**（a）**：只允許密碼
- 模型**（b）**：允許附加數據
此處的附加數據可能是使用者語言、連結或電子郵件地址的評論/評論。
密鑰庫 SALT 用於蘋果加密函式CCKeyDerivationPBKDF，它將使用者密碼擴展到 256 位以用於 AES256。
- 如果密鑰庫 SALT 在所有密鑰上共享，那麼在密鑰庫中允許多個密鑰是否安全？
由於應用程序接受每個條目都是有效的，因此無法檢測到使用的密碼數量。您必須決定密鑰是否有效。對於應該知道正確密碼的使用者來說也是如此。
- 攻擊者可以使用共享的 SALT 進行某些攻擊嗎？
- 當我使用允許攻擊者猜測的模型**(b)時是否存在安全風險，加密條目中存在使用者語言（或連結/電子郵件地址）？**
問題陳述
你有一個消息列表 $ (m_1, m_2, \dots, m_n) $ ，可能帶有相應的標籤/描述 $ (t_1, t_2, \dots, t_n) $ ，您要儲存的。您希望保護消息（但不是標籤/描述）的機密性，使其免受破壞您儲存的攻擊者的侵害。你有一個秘密密碼 $ pw $ 由你處置。
攻擊者可能知道/能夠猜測部分或全部的部分或全部消息。
您的解決方案
您提出的建議（基於 AES-OFB， $ c = \mathrm{AES{-}OFB{-}}\mathcal{E}(k, m) $ , $ m = \mathrm{AES{-}OFB{-}}\mathcal{D}(k,c) $ , 加密算法生成 IV 並將其包含在密文中；您的軟體可能有不同的界面）：
- 生成鹽 $ s_0 $ .
- 對於每個條目，生成一個鹽 $ s_i $ .
- 對於每個條目，計算 $ k_i = \mathrm{PBKDF2}(pw, s_0 || s_1, \mathit{iterations}) $ .
- 計算 $ c_i = \mathrm{AES{-}OFB{-}}\mathcal{E}(k_i, m_i) $ .
- 儲存兩個列表 $ (c_1,c_2, \dots, c_n) $ 和 $ (t_1, t_2, \dots, t_n) $ .
問答
**問：**您需要每次輸入的鹽嗎？ **答：**不會。對於已經入侵許多使用者商店的攻擊者來說，鹽是為了讓每個密碼片語的搜尋成本保持較高水平。鹽 $ s_0 $ 足夠了。
**問：**對手可以猜測/知道部分消息是否存在問題？ **答：**不可以。AES-OFB 可針對選定的明文攻擊提供機密性。
比你要求的多
你不應該自己做這種設計，也不應該依賴隨機網站上的建議。
- 不要認為對手無法辨識正確的密碼。
- 不要假設使用者將能夠辨識錯誤的解密。
- 不要使用OFB模式。它有時效率低下並且不提供完整性。
以下自然建議比您的更好（基於 AES-GCM，一種對稱加密方案，可加密消息並保護相關數據的完整性： $ c = \mathrm{AES{-}GCM{-}}\mathcal{E}(k, ad, m) $ , $ m = \mathrm{AES{-}GCM{-}}\mathcal{D}(k, ad, c) $ . （請注意，我假設加密算法會為每個加密生成一個新的 IV/nonce 並將其附加到密文中。您的軟體可能有不同的界面。））
- 選擇鹽 $ s $ .
- 使用 PBKDF2（或類似的東西）派生密鑰 $ k $ 從 $ s $ 和 $ pw $ ，使用合適的迭代次數。
- 將每個秘密加密為 $ c_i = \mathrm{AES{-}GCM{-}}\mathcal{E}(k, i || t_i, m_i) $ .
- 儲存兩個列表 $ (c_1, c_2, \dots, c_n) $ 和 $ (t_1, t_2, \dots, t_n) $ .
PS。不要使用您在網際網路上免費獲得的方案。