IV 對加密數據庫 ID 無用嗎？
在我的場景中，我需要建構一個偽匿名化服務：一台給出
plainID返回 a的機器，chiperID反之亦然。chiperID在提供未知數時創建plainID。所以我有一個身份表，通過儲存這對來跟踪這個映射[plainID-chiperID]。為了防止直接訪問數據庫，我需要加密其中一個，以便實際儲存[encryptedPlainID-chiperID]我的應用程序是唯一需要加密和解密 ID 的應用程序，因此我將使用對稱加密算法，如 AES-256-*，其中密鑰由應用程序保存。
因此：
- 通過
plainID提供chiperID應用程序需要直接查詢身份表chiperID然後解密來獲取encryptedPlainID.- 反之亦然，
chiperID通過提供plainID應用程序首先需要對身份表進行加密plainID，然後通過身份表查詢身份表encryptedPlainID我知道不使用 IV 會使算法不安全，但我懷疑儲存 IV 以供以後解密以及加密的 ID 會使整個系統安全。要清楚，我想知道我是否需要在身份表中儲存三元組
[encryptedPlainID-IV-chiperID]但是對於這個模式，我不能做到第 2 點，因為我不知道用於加密的先驗 IV
plainID我能做些什麼？分組密碼的操作模式重要嗎？
操作模式並不重要。它定義了 IV 的屬性！操作模式是指定IV的大小、IV的內容以及濫用IV的影響的部分。AES 是分組密碼；它本身只允許密鑰和單個消息塊作為輸入；AES 本身沒有指定或知道任何 IV。
例如，CBC 模式需要一個與塊大小相同的不可預測（讀取：隨機）IV，以用於常見的加密目的。如果您未能提供它，那麼對手可以檢測到相同的密文塊並在同一位置檢索明文塊的資訊——很可能包括 ID。
另一方面，GCM 模式預設為 12 字節 IV（儘管其他大小也是可能的）。IV 實際上只是一個（二進制）隨機數：一個使用一次的數字；只要它從不重複相同的鍵，你就可以了。但是，如果它失敗了，那麼您可以將密文進行異或運算以檢索兩個不同明文的異或 - 這將很快導致大多數類型的明文的機密性完全破裂。
很多時候，IV 只是簡單地添加到密文之前。大多數操作模式都有一個靜態大小的 IV（如果沒有，您可以為您的特定協議標準化 IV 大小）。使用加密安全的隨機 IV 是一種行之有效的做法，您可以將其用於您的特定問題，只要您的數據庫能夠儲存擴展的密文。
如果您還希望 ID 受到完整性保護，您可能還需要用於身份驗證標籤的儲存空間。為此經常使用諸如 GCM 之類的模式；身份驗證標籤通常為 8 到 16 個字節（當然，16 個字節提供了最大的保護）。HMAC 也可用於完整性保護，在這種情況下，IV 應包括在計算中。
這將我們帶到了靜態 IV (SIV) 操作模式。使用 SIV，IV 兼作身份驗證標籤。對於 SIV 模式，明文的唯一性保證了 IV 的唯一性。它比 IV + 身份驗證標籤具有儲存優勢，並且不需要任何單獨的隨機輸入或狀態機（用於隨機數/計數器）。儘管它確實擴展了密文大小，但它似乎非常適合加密 ID 值——只要它們不會為多個使用者重複。
還有 AES-GCM-SIV 將 AES-GCM 的效率帶入 SIV 模式。原始 SIV 使用 AES-CMAC 作為身份驗證機制。
如果 ID 是唯一的並且適合單個塊，那麼您可以簡單地使用單個塊加密來儲存 ID。請注意，這很脆弱；如果有人決定擴大 ID 大小，那麼該方案很可能會失敗。如果分組密碼不直接可用，您可以為此使用 ECB 模式。IV 為零的 CBC 模式將對第一個塊執行相同的操作。當然，使用 ECB 或 CBC 會使方案更加脆弱；使用兩個或更多塊可能會引入漏洞。
最後，如果您需要將 ID 儲存在相同數量的數據中，那麼您可以查看 Format-Preserving Encryption (FPE)。這是一種效率較低的模式，具有較高的學習曲線和有限的支持。與 SIV 模式一樣，它依賴於輸入的唯一性來實現機密性。它的主要優點是它不會在明文大小上擴展密文，無論明文佔用多少數據。換句話說，它不受塊大小的限制。
筆記：
- 將隨機 IV 儲存在數據庫中的其他位置也很好，例如在單獨的行中。
- 添加身份驗證標籤只能針對主動攻擊提供有限的保護，例如攻擊者交換不同使用者的加密 ID。通常，數據庫是關於保護靜態數據的，例如在數據庫被盜的情況下提供 ID 的機密性。由您決定身份驗證標籤所需的額外空間是否物有所值。
- 請注意，消息/ID 也可能會及時重複。依靠 ID 的唯一性可以例如仍然允許對手跟踪特定使用者的 ID。這是否是攻擊向量取決於具體的案例。