使用 HMAC-SHA-256 的基於計數器的密碼
在嘗試發明自己的 AES 模式後，我決定只實現一些已知可行的方法，即使用 HMAC-SHA-256 的 CTR 模式。
- 據我了解，我可以將 IV 用作計數器，並且 IV 只需對每個鍵都是唯一的（生成唯一的 IV 不是問題）。正確的？
- 如果我使用 32 字節密鑰、16 字節計數器和 16 個零字節進行填充構造一個 SHA 塊，是否是 HMAC-SHA-256 的問題，或者生成一個 64 字節密鑰以便它適合一個 SHA 塊和為計數器製作另一個塊並用零字節填充該塊？
- 如果我想給任何東西加鹽，我假設鹽是未加密儲存的。正確的？
編輯以清除一些東西：
使用 IV 作為計數器意味著它會隨著每個加密塊的變化而變化。在這種情況下，我將直接使用 12 字節大的作業系統的簡單時間戳（解析度以滴答為單位，即 1/50 秒，軟體在生成 IV 之前等待一個滴答，系統很慢所以不是問題）。剩餘的四個字節用作塊計數器（簡單地從零開始）。
預期的 HMAC 設置是：
第一個 SHA-256 消息由第一個 HMAC 密鑰、IV、填充和密文組成。第一個 SHA-256 塊將是第一個 HMAC 密鑰（32 個字節），然後是 16 個字節的 IV，然後是 16 個字節的零填充。消息的剩餘塊是密文塊，在最後一個密文塊之後具有正常的 SHA 填充（正常 SHA 操作）。生成的散列是第一個 HMAC 散列。
第二個 SHA-256 消息是第二個 HMAC 密鑰（32 個字節），然後是第一個 HMAC 雜湊（32 個字節），最後是正常的 SHA 填充。這是身份驗證標籤。
第二次編輯：
在網上搜尋了一些之後，我發現我對 HMAC 密鑰的使用方式做了一些假設。我使用了 NIST 的一些測試向量來驗證我做事是否正確，現在就是這種情況。
正確的 HMAC-SHA-256 設置：
獲取第一個 32 字節 HMAC 密鑰，附加 32 個零字節，對生成的 64 字節塊進行異或 IPAD，附加密文，散列。
取第二個 32 字節 HMAC 密鑰，附加 32 個零字節，對生成的 64 字節塊進行 XOR OPAD，附加第一個散列，散列。
我假設您可以將隨機數添加到密文中，以便它也被散列。正確的？
據我了解，我可以將 IV 用作計數器，並且 IV 只需對每個鍵都是唯一的（生成唯一的 IV 不是問題）。正確的？
不完全是。每個密鑰的每個塊的 IV 必須是唯一的。您可以將消息計數器用於 IV 的 Nonce 組件，然後塊計數器組件從 CTR 中的 0 遞增。
IV = [96-bit Message NONCE][32-bit Block COUNTER]由於 Nonce 不是隨機的或不可預測的，因此消息計數器是合適的。我使用消息計數器、時間碼和隨機數的組合，所有 32 位，如果計數器被惡意重置，這有助於防止意外的 nonce 重用。在消息計數器溢出之前需要更改密鑰。
IV = [32-bit RANDOM][32-bit Timecode][32-bit Message CTR][32-bit Block CTR]還有其他方法可以使用。您可能不希望時間碼資訊與消息一起發送，或者讓攻擊者知道您發送了多少消息。您甚至可以在 CTR 模式下使用之前用另一個密鑰加密隨機數，但是您需要為此進行自定義設置，因為它可能做得非常錯誤並破壞安全性。
如果我使用 32 字節密鑰、16 字節計數器和 16 個零字節填充來構造 SHA 塊，HMAC SHA256 是否有問題，或者生成一個 64 字節密鑰更好，以便它適合一個 SHA 塊並製作另一個塊對於計數器並用零字節填充該塊？
這將改變 HMAC 的操作方式，即僅將密鑰作為密鑰輸入。每個規範的 HMAC 只會在大於塊大小的情況下對密鑰輸入進行雜湊處理，因此您可以輸入 512 位的“密鑰”數據，儘管不必將計數器作為輸入的一部分。將隨機數附加到密鑰不應該對安全性產生任何負面影響，甚至可能會加強它，但我不會肯定地說。如果您希望對其進行身份驗證，最好將隨機數添加到消息輸入中，而不是將其添加到密鑰中。將計數器包含在密鑰中還會消除您可以使用的特定類型的性能優化。
您可能需要考慮 SHA-512/256 或 SHA-3-256。如果您有 64 位程式碼和可用的 CPU，它會更快，並且應該更安全地抵禦目前和未知的攻擊。使用 SHA3 的 MAC 不同，它在消息前面加上密鑰。
如果我想給任何東西加鹽，我假設鹽是未加密儲存的。正確的？
鹽是一段非秘密的加密資訊，因此不需要加密。如果您認為它有可能被意外更改，您可能想要添加某種冗餘檢查或重建奇偶校驗（例如 Reed-Solomon）以與之關聯。在某處保留備份，沒有鹽的密碼將意味著失去的密鑰。
最後，確保您為密碼和 MAC 使用不同的密鑰。原因是對其中一個的攻擊可以破壞兩者。雖然這可能不太可能，但使用單獨的密鑰仍然是一個好主意，並且符合 FIPS。
我決定只實現一些已知有效的東西，即使用 HMAC SHA256 的 CTR。
所以你到底是在實施自己的模式嗎？不。將 MAC 和加密結合起來實際上很棘手。您應該使用標準的經過身份驗證的加密模式，例如GCM（即 CTR 加 MAC 正確完成）。
據我了解，我可以將 IV 用作計數器，並且 IV 只需對每個鍵都是唯一的
對於 CTR，IV（更恰當地稱為初始計數器）對於給定鍵的每個塊需要是唯一的。例如，如果您開始使用計數器值 0 加密 3 塊消息，這也會用完計數器值 1 和 2，因此下一條消息必須以計數器值 3 開頭。初始計數器不需要是隨機的（但這通常是使它獨一無二的好方法）。可以使用具有不同鍵的相同計數器。
如果我使用 32 字節密鑰、16 字節計數器和 16 個零字節進行填充建構 SHA 塊，HMAC SHA256 是否有問題，還是生成 64 字節密鑰更好
我不明白這一點。HMAC-SHA256 使用 32 字節的密鑰。消息的大小和結構與密鑰的大小無關。
如果我想給任何東西加鹽，我假設鹽是未加密儲存的。
是的，這就是鹽的定義：需要是唯一的（在某個域內）並且不需要保密的東西。