帶 bcrypt 密碼去偏的 XOR 加密
目標：有一個非常簡單的驗證，但非常安全的小消息加密。
想法： 消息⊕ bcrypt(密碼)。我們使用 Message 刪除密碼偏差，
bcrypt然後使用 XOR 結果密鑰。實施。
限制：僅支持長度不超過 320 個字元的消息。
10 個
bcrypt鹽值是硬編碼的：
- 鹽1 =
$2a$12$geKv/Jdb2zSGEtnn3AuXXe- 鹽2 =
$2a$12$h1V42zCLf/F5F7RbueVuZe- 鹽3 =
$2a$12$UTX8OMvg1CI3/pnbT0F5Mu- . . . . . . .
- 鹽10 =
$2a$12$Yq9Vo0yefk6zJlEvJmBf6O假設我們有
留言=
My safe code is 29540323, my bank card pin is 6926密碼=
32GateKeepers消息長度為 50 個字元。bcrypt 生成 32 個字元長的密鑰。所以我們需要 2 個鍵來匹配消息長度：
鍵1 =
bcrypt(Password, Salt1) = e8.4zyJT9m9R/KX./Kd2juSHn25IqGUO鍵2 =
bcrypt(Password, Salt2) = emTDJsUVCLFE3Jm8Cjx2S2/WmXEVrrU.密鑰（50 個字元）=
e8.4zyJT9m9R/KX./Kd2juSHn25IqGUOemTDJsUVCLFE3Jm8Cj程式碼=消息⊕鍵=
40,65,14,71,27,31,47,116,90,2,93,55,15,34,43,14,29,114,81,6,90,70,97,123,66,18,88,48,81,37,52,33,14,77,55,37,56,23,117,38,42,34,102,44,64,106,91,1,113,92問題：
bcrypt去偏是否足以在 XOR 加密中使用？具體問題：攻擊者知道相同的密碼用十個已知的鹽進行雜湊處理以獲得更長的消息。
具體問題：如果攻擊者有 10 個相同密碼的雜湊值和 10 個已知鹽。鑑於雜湊的性質，這會削弱密碼嗎？
每當您對密碼散列算法進行多次評估時，只有在您做錯事情時才執行它是一種合法的選擇。原因如下：
如果一個雜湊評估成本 $ C $ ，那麼具有相同成本參數的 10 個雜湊將花費 $ 10 \times C $ .
散列可以由破解者評估，每個候選密碼的成本與 $ C $ . （可能比 C 少很多，因為他們可以建構或購買針對密碼破解進行優化並專門用於密碼破解的系統。）
給定 $ x = H(\text{salt}, \text{password}) $ , 可以猜出一個候選密碼 $ p $ 並比較 $ x $ 至 $ y = H(\text{salt}, p) $ .
- 如果 $ x \neq y $ 然後 $ \text{password} $ 不是 $ p $ .
- 如果 $ \text{password} $ 不是 $ p $ 然後 $ x = y $ 只有 $ 1 / N $ 機率在哪裡 $ N $ 是雜湊圖像集的大小。*
鑑於一些知識 $ n $ - 一個雜湊輸出位的長子集，破解者可以類似地評估一個候選密碼的雜湊值 $ \le C $ 與 $ 2^{-n} $ 假陽性率。
- 如果對手知道一個明文字元（8 位），那麼每 256 個候選密碼，可以消除 255 個候選密碼，工作量為 $ C $ . 每 256 個中只有 1 個需要兩次或更多雜湊函式評估來檢查誤報。
- 因為每個 32 字節塊都可以獨立測試，密碼破解者很少需要做比例 $ 10 \times C $ 工作，但合法的密碼持有者將永遠這樣做 $ 10 \times C $ 工作，
- 與其他方法相比，破解者比誠實方具有顯著優勢：使用單個密碼雜湊評估（基於密碼的密鑰派生函式）來計算一個密鑰，並將該密鑰與典型的對稱密鑰消息加密算法一起使用。
可以將密鑰派生函式（您可以將其視為用於確定性生成密鑰的雜湊函式）分為兩類：基於密碼的 KDF 和基於密鑰的 KDF。
“密碼雜湊”（或非專家有時所說的“慢速雜湊算法”）用於描述“拉伸”密碼的基於密碼的功能。密碼通常是低熵的（也就是說它們是相對可預測的），因此密碼雜湊和 PB-KDF 旨在人為地減慢合法方和密碼破解者的評估速度，以期降低密碼破解的“利潤”。
標准或“快速”雜湊算法不一定因為它們速度快而不安全。如果密碼像 128 位密鑰一樣不可預測，那麼密碼庫可以只儲存密碼的 SHA-2 雜湊值（最好仍然出於偏離主題的原因加鹽）而不會損失安全性。
正確的做法是將密碼散列算法的成本參數增加十倍。你做著同樣多的工作，
$$ 1 \times (10 \times C) = 10 \times (1 \times C) $$因此您的 CPU 時間預算不會增加。另一方面，只有一個較慢的雜湊函式可以破解的對手現在需要始終按比例執行 $ 10 \times C $ 工作而不是僅僅 $ C $ 工作。 如果您需要的密鑰材料多於 PB-KDF 所能提供的數量，但不會增加您需要做的工作量，那麼只需從 PB-KDF 派生一個主密鑰，並將派生的密鑰提供給 KB-KDF。您可以從基於密鑰的密鑰派生函式中派生許多密鑰，這比密碼散列函式的執行時間要快得多。
如果由於某種原因您必須僅使用雜湊算法而不是流密碼，那麼請執行
$$ K_M = bcrypt_{10 \times C}^\text{**}(\text{salt}, \text{password}) $$ $$ K_i = \text{SHA-512}(K_M | i | \text{nonce}) $$ $$ \text{ciphertext}_i = \text{plaintext}i \oplus K{i + 1} $$ 並且寄出
$$ \text{ciphertext} | \text{HMAC-SHA-512}(K_0, \text{ciphertext}) $$ 因為除了消息保密之外，您還需要消息身份驗證。 在我之前的成本分析中，我將密鑰流計算視為零。如果選擇大 $ C $ 那麼這是一個合理的假設。否則假設很少 $ c $ 是“快速”雜湊的成本。你的 CPU 成本是 $ 10 \times C + 13 \times c $ . （因為 HMAC 是另外 2 個雜湊值，而您又為 HMAC 派生了一個密鑰。）而對手的成本是 $ 10 \times C + c $ . 但兩者都差不多 $ 10 \times C $ .
對於您的具體建議，假設您使用純文字的 ASCII 編碼，您可以輕鬆推斷每個完整 32 字節塊的 32 位，因為沒有標準 ASCII 字元具有設置最高有效位的字節值。
對於其他類型的明文，它不一定那麼微不足道，但您應該假設還有其他一些方法可以猜測明文。如果存在不確定性，那麼對手可以將更多明文猜測與相同的雜湊評估進行比較。你顯然會得到更多的誤報，但這並不能防止破解。通過評估每個鹽的雜湊值，然後查看解密以查看它是否有意義，可以將誤報與真陽性區分開來。（檢查它是否包含真正的字典單詞，或者進行統計測試，將其與合理的明文進行比較。）
- 假設雜湊函式是無偏的，這對於好的密碼雜湊算法和許多常見的不好的算法來說是合理的。（SHA-1 和 MD5 包括在其他不好的情況中。）對於普通舊密碼散列案例（不是您的使用）誤報（這是不可能的，可以肯定地說它們不會發生）和真正的積極因素。
** 如果優化的實現可用而不是 bcrypt，則使用 Argon2d。如果 bcrypt 有一個優化的實現，它就很好。PB-KDF2 和氣球雜湊也是如此。（不要要求 PB-KDF2 輸出長度太長。）如果有優化的實現並且可以給它較大的 CPU 和 RAM 餘量，您也可以使用 scrypt。…我開始看到人們聽到“使用 ___ 而不是 ___ 進行密碼散列”的建議現在開始接觸到更多的受眾，並且正在消除類似於貨物崇拜的想法，即它意味著“總是替代$$ password hashing function $$為了$$ normal hash algorithm or encryption algorithm $$“。這是錯誤的。僅使用密碼散列函式來儲存密碼和派生主密鑰。
編輯：Argon2d。不是 Argon2i。
美好的一面
由於這是一次性加密，您可以將其用於伺服器和客戶端之間的流式傳輸。您可以使用 RSA 等非對稱加密來傳遞您所稱的對稱加密密鑰
Password。Vernam Cipher 是 1917 年發明的一種算法，用於加密電傳打字 (TTY) 消息。
鹽不需要硬編碼。我會使用 1, 2, 3, … 假設雜湊算法足夠強大。
陰暗面
但是，Vernam 加密系列又名一次性密碼 (OTP) 有一個很大的缺點。您不能多次使用它們。你可能會問有什麼問題？如果密鑰是由隨機生成器生成並通過安全方法傳遞給客戶端的，您可能不在乎。因為下次你會生成另一個密碼。
但是，如果您在磁碟上使用人類可讀的密鑰，例如
password123and 加密file1，您可能希望使用相同的密碼加密file2,file3and …。這就是問題所在。即使我沒有你的密鑰和鹽，但我知道是空的
file10並且加密的file10.enc開頭是無論您的密碼和鹽是什麼。相比之下，不存在這樣的漏洞。這就是差異的來源。ba61dc7bca877c3006663212fe``XOR``file2.enc``file2``file2.enc``AES encryption希望我明白你的意思。