將 AES 相關數據和 PBKDF2 相關數據（密碼除外）儲存在一個文件中是否安全？
假設包含以下數據的*“加密數據包”文件格式*
PBKDF2
- 算法
- 鹽
- 回合
- 凱倫
AES
- 算法與模式
- 四
- 密文
其中 PBKDF2 salt 和 AES IV 是在單獨加密時使用 CSPRNG 生成的。
這將使個人密碼（用作 PBKDF2 輸入參數）成為儲存在安全位置的唯一單獨儲存的數據（*“加密數據包”*文件的秘密）。
將 AES 相關數據和 PBKDF2 相關數據（密碼除外）儲存在一個文件中是否安全，或者這樣做是否有任何加密含義？如果有影響，將 PBKDF2 數據與 AES 數據分開儲存有什麼優勢（從安全形度來看）？
在描述潛在的陷阱時，最好將答案假設並擴展以下兩種情況：
- AES-256-CTR，將 PBKDF2 參數簡單地添加到密文前面，以及
- AES-256-GCM，將 PBKDF2 參數作為關聯數據輸入 AES 模式。
將此更多地視為一個規範問題，暗示
- *“單獨的儲存是否類似於混淆的安全性？” 和
- “我們需要在安全位置儲存的最少數據是多少，以及我們可以在密文旁邊‘公開’安全地儲存哪些其他數據，這樣我們就不會引入密碼問題？”
您提到的所有參數都可以公開。此外，不能簡單地猜測只有鹽、IV和密文。
一旦知道密鑰，IV 通常很容易檢索，因此製作 IV 秘密沒有意義。在 CBC 模式和許多其他模式下，如果 IV 完全不存在，您可能無法獲得第一個明文塊，但其餘密文將可用。在 CTR 模式下，一旦知道密鑰並且知道第一個明文塊的一部分，您將直接獲得 IV。
所以基本上就剩下鹽了。現在鹽有時會部分保密。這個靜態的、秘密的部分被稱為辣椒。如果您保持此安全，則可以將其視為生成結果輸出密鑰所需的附加輸入密鑰。仍然應該有一個隨機或至少唯一的鹽，否則相同的密碼將導致相同的密鑰，這絕對是您想要避免的事情。
TL; DR 你可以使用辣椒，如果辣椒有不同的訪問要求，這有時是有意義的。所有其他資訊都可以簡單地與密文一起儲存（但請繼續閱讀）。
請注意，使用密文儲存算法時肯定存在危險。問題是，如果攻擊者可以將算法從 GCM 切換到 CTR，那麼您會突然獲得未經身份驗證的明文。您最好確保攻擊者不能簡單地更改一些參數來降低您的協議的安全性。
這比將任何這些公共參數與密文一起儲存要危險得多。
如果您決定使用經過身份驗證的密文，那麼可以，請將所有參數作為附加驗證數據 (AAD) 的一部分。請注意，所有 AEAD 模式都已在驗證中包含 IV，因此絕對沒有理由將其包含在 AAD 中。