雙CBC作為AES-KW的替代品？
背景。
我正在嘗試製作一個基於本地命令行的密碼管理器。到目前為止，我已經設法讓 tty 上的輸出看起來令人頭暈目眩，並且我計劃在單獨的 512 字節塊中編碼使用者憑據。
為了加密這些塊，我考慮過使用 XTS，但是與 NIST.SP.800-38F 中的密鑰包裝模式相比，“調整”的成本使它不太有利。
但是 NIST.SP.800-38F 中的密鑰包裝涉及將塊分成兩半成“半塊”，這有點令人反感，完全實現它意味著各種工作變數的複雜化。
所以我做了一個臨時設計。
雙CBC。
在 2CBC 模式下，明文經過兩輪加密。
在第一輪中，AES-CBC 被應用於具有全零 IV 的數據，並且由於密碼輸出的連結，我們可以確定最後一個塊的結果取決於所有先前的塊。
在第二輪中，再次應用 AES-CBC，但這一次，第一輪的最後一個塊作為 IV，因為 IV 是密碼的輸出，我們可以確定它是適當隨機的，因為它是輸出密碼鏈，我們可以確定它取決於輸入的所有部分。
我覺得實現 2CBC 比 AES-KW 更容易。
關於完整性和語義安全。
因為塊對於它所保存的數據類型來說足夠大，所以在 512 字節塊的內容中可能有專門的區域用於隨機化向量和完整性檢查值。
具體來說，最後 128 位將具有 1.) 96 位隨機化值，2.) 所有先前 508 字節的 CRC32 校驗和。
但是，我看不出需要消息身份驗證的原因，因為它主要是靜態數據。但是，我不確定這對於這裡的案例是否足夠。具體來說，我需要什麼樣的對手來防止記錄被篡改，以及如何。
問題。
- 我的論點是否足以聲稱 2CBC只是為了保密而安全？還是我犯了一個可怕的錯誤，錯過了一些重要的事情？
如果我想增加完整性，我可以像從 W 擴展 KW 那樣做嗎？- 隨機化值是否必須不可預測？我可以提供有意義的資訊，例如修改時間嗎？（可能不會，因為如果攻擊者檢查文件的修改時間，他/她會知道文件中有一些已知的明文）。
- 應如何滿足對記錄進行驗證的需要？
讓我們假設記錄結構的最終設計可以出於安全性和其他各種原因進行更改。
- CBC 模式要求使用相同密鑰的每次呼叫都有一個統一隨機且唯一的 IV。出於問題中提到的原因，第二輪的 IV 對此屬性感到滿意。
這基本上是一個大塊上的確定性偽隨機排列，並且可以（並且應該）通過在塊內添加隨機化來添加語義安全性。 2. 既然這個問題已經被削減了，讓我們在這里分開關注點。 3. 目前不知道諸如 AES 之類的現代密碼會被 KPA 懷疑。由於 2CBC 密文的每一位都是 AES 加密函式的輸出，因此這種擔憂可以說是微不足道的。 4. 如前所述，分離關注。
首先我們應該重新設計記錄結構，我們可以有128字節的登錄站點，128字節的使用者名，128字節的密碼，64字節的隨機化。（當字元串以 nul 結尾時，問題中所述的其餘空白區域也可用於隨機化）
這些是要使用 2CBC 加密的內容。接下來，我們使用一個單獨的密鑰（假設我們有一個用於派生加密和身份驗證密鑰的 KDF）到 HMAC-SHA512 加密數據，並在末尾附加一個 64 字節的 MAC 以形成完整的 512 字節記錄。
還請記住，如果您不確定是否需要消息身份驗證，請在發現自己不得不破壞反向單詞兼容性之前擁有它，收益應該總是大於痛苦。