384 位 ChaCha20 / Salsa20
標準 Salsa20 核心是 $ {0,1}^{384} \to {0,1}^{512} $ 具有 16 字節常數的隨機函式 ( $ \sigma $ 對於 32 字節密鑰)、8 字節隨機數、8 字節計數器和 32 字節密鑰。散列函式不區分輸入類型。這留下了 48 個字節,可以隨機選擇。如果它們都是隨機選擇的並且是保密的,這是否會增加密鑰空間到 $ 2^{384} $ ,或者密碼的內部狀態限制為 256 位是否有某種原因?我問這個是因為 Linux 核心隨機驅動程序(稱為 CRNG)使用 ChaCha20 來生成隨機性。
密碼狀態在 Linux 核心中使用以下函式進行初始化:
static void crng_initialize(struct crng_state *crng) { int i; unsigned long rv; memcpy(&crng->state[0], "expand 32-byte k", 16); if (crng == &primary_crng) _extract_entropy(&input_pool, &crng->state[4], sizeof(__u32) * 12, 0); else _get_random_bytes(&crng->state[4], sizeof(__u32) * 12); for (i = 4; i < 16; i++) { if (!arch_get_random_seed_long(&rv) && !arch_get_random_long(&rv)) rv = random_get_entropy(); crng->state[i] ^= rv; } crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1; }
狀態,保持在
(struct crng_state *)crng->state
,具有常數 $ \sigma $ 對於前 16 個字節,後 48 個字節是使用 隨機生成_extract_entropy()
的,該函式返回請求的熵量。這是否意味著 CRNG 輸出具有 $ 2^{384} $ 鍵空間?如果對 ChaCha20 的攻擊至少需要 $ 2^{256} $ 密碼的呼叫,然後增加密鑰大小不會增加安全性(即使 256 已經足夠了)。也就是說,256位密鑰的ChaCha20是256位安全的,但我不知道384位密鑰的ChaCha20是否是384位安全的。對於 384 位密鑰,沒有比暴力破解更快的攻擊嗎?
我完全意識到,即使是一個好的 256 位密碼也被認為不可能用現代技術破解,並且沒有實際理由使用更大的密鑰。然而,有時了解給定數量的偽隨機數據中存在多少熵是有用的。
是的,您可以控制 $ 32 $ -字節鍵 + $ 8 $ -字節隨機數+ $ 8 $ -字節計數器總計為 $ 384 $ -bit 密鑰,這是非常安全的。
您對此功能的唯一責任是確保 $ (\text{Key}, \text{Nonce}) $ 元組從不重複。PRG 將遞增並包裝計數器,因此這可能會開始隨機化。您仍然可以增加隨機數。您可以(但可能不應該)增加密鑰。
或者,您可以使用更標準的 IETF 變體 chacha20 和 96 位隨機數和 $ 32 $ 位計數器或 Xchacha20 變體 $ 192 $ -bit 隨機數,沒有暴露的計數器。
編輯:我們如何確定 chacha20 不限制為 256 位安全性?
常量、key、nonce 和 counter 都被同等對待,使得 $ 1 $ - $ 2 $ 計數器中的位變化是安全的。常數的存在是為了權衡對手對功能的控制。對手可以控制 $ 8 $ -字節隨機數和 $ 8 $ -字節計數器,而不是 $ 32 $ -byte 鍵也不 $ 16 $ -字節常量。 $ 16 / 64 = 1 / 4 $ . 如果對手可以控制常數,那麼他們有 $ 1 / 2 $ 的輸入。滿滿的 $ 384 $ -bit key只給對手知識的公共常數(他們知道計數器增量)。一個 $ 512 $ -bit key 意味著對手不知道任何輸入。