加密用於冷儲存的加密貨幣種子
我想要一些關於加密算法的回饋。我不是自己動手，但即使將經過充分驗證的部分放在一起也可能會造成許多陷阱。（我不知道我是否在這個論壇上提出質疑。我正在就具體的、潛在的陷阱進行具體的回饋。）
目的：
- 加密加密貨幣種子（即密鑰）的冷儲存。
編輯：種子（在這個問題中使用）是超級秘密明文。但通常稱為種子，因為它通常是二進制數組，而不是 ascii。
目的與BIP0038相同（ 請參見下面的摘要）。*
肯定存在有人重複使用密碼的可能性。
該算法應盡可能簡單，以避免實現中的錯誤。
我的建議：
- 生成加密隨機種子（32 個字節）（或來自使用者*
的輸入）* 編輯：種子是 32 個隨機字節。如果她願意，使用者可以輸入在其他地方生成的加密隨機種子。種子用於生成公共地址。有點像私鑰/公鑰對。我想加密和儲存的是私鑰，即種子。） 2. 輸入來自使用者的 UTF-8密碼，應用規範規範化 3. 生成加密隨機鹽（12 字節） 4. （可能要求輸入“ toughness ”，以調整 argon2id 參數。）
.
- 使用 Argon2id，使用 2) 和 3)生成 32 字節加密密鑰。
我猜 argon2id 選項完全是一個單獨的主題。
我認為迭代 = 2 （一些東西 + 韌性）
.
- 使用 AES-CTR加密種子1)，使用 3) 中的**鹽作為計數器，使用 5) 中的加密密鑰。
- 加密種子(6) + Salt (3) 連接起來，base32 編碼為大寫，做最緊湊的二維碼，附加 ‘:T’ + < toughness >。
.
我的推理和問題
有什麼絆線讓我自己糾結過嗎？
AES-GCM 優於 AES-CTR。 GCM 有消息認證。但我不認為延展性是一種攻擊媒介。你還不如把這張紙燒掉，而不是在二維碼上亂塗亂畫。
A)在這個案例中 GCM 和 CTR 是否同樣好？如果重複使用相同的密鑰和計數器，兩者都會發生災難性故障。（沒有區別，我知道。）
**B)**生日問題。為什麼是 12 字節鹽？
打開輸入。:)
閱讀生日攻擊 - 維基百科，如果我的數學是正確的：
每 5x10^9 重用密碼片語，一個 8 字節的鹽就會產生一個可能的生日沖突。
每 3x10^14 次重用密碼片語，一個 12 字節的鹽就會產生一次可能的生日沖突。但經過 base32 編碼後
，它將適合相同大小的QR 碼。（版本 3，ECC 級別 L。）
C) 16 字節的鹽仍然更好。但有必要嗎？
關於 Argon2id 的任何注意事項？
**D)**鹽被重複用於兩個不同的操作是否存在問題？（Argon2id 和 AES）
E) AES CTR 與 CBC？種子長度為 32 字節，因此CBC 不需要填充。兩者都需要一個隨機計數器/iv。它們是否同樣適用於這個案例，或者其中一個更適合這個問題？
為什麼選擇base32？因為 QR 對大寫和數字進行了優化編碼。這裡的安全不僅僅是黑客攻擊。無法讀取的二維碼同樣具有災難性。
Keepass 在這方面也做得很好。
我的案例是可掃描的紙。如果我被公共汽車撞到或從懸崖上掉下來，我的妻子可以使用它。:)
如果這篇文章有點長，我很抱歉。但是，將這些步驟放在一起會導致安全性崩潰。
歡迎任何評論。:)
vbakke
.
- BIP38。https://en.bitcoin.it/wiki/BIP_0038使用 scrypt，並首先對密碼進行 2xsha-ing。鹽來自密碼片語，因此重用密碼片語是一個問題。
BIP38 感覺過於復雜。就像有人打了很多不好的結，而不是正確地打一個結來固定負載。簡單也是安全的。
除非另有說明，否則我假設對手知道真正的 QR 碼，並且可以對其進行更改並送出以進行解密。我認為設計要求是：
- 的保密性 $ \text{seed} $ ,達到Argon2的密碼 +密鑰擴展允許的最高級別。
- 完整性 $ \text{seed} $ , 到 64 位安全級別$$ ample in the context, where we want to catch an incorrect passphrase, or an altered QR-code which decryption is attempted in a legitimate context, with some low limit on how many times $$.
- 能夠編碼任意 $ \text{seed} $ [例如，因為它是獨立於程序生成的；這也是允許更改密碼而不更改的必要條件 $ \text{seed} $ ].
我建議擺脫 AES-GCM，因為我們可以不用它，而且大多數可移植實現 [不使用AES 指令] 使用可以創建邊通道的數據相關記憶體訪問。此外，問題 A/D/E 也解決了。朝著這個方向：
- 在第 5 步，生成 64 個字節$$ that is set 64 for tagLength in the invocation of Argon2 $$. 將輸出拆分為前 32 個字節 $ K_0 $ , 和最後 32 個字節 $ K_1 $ .
- 為了保密，計算 $ C\gets K_0\oplus\text{seed} $ 並將其編碼為二維碼。在解密時，做 $ \text{seed}\gets K_0\oplus C $ .
- 為了完整性，請使用 Argon2i$$ 1 for hashType $$和 $ C $ 作為鹽， $ K_1 $ 作為密碼，8 作為標籤長度，最小工作因數$$ that is 1 for parallelism, 8 for memorySizeKB, 1 for iterations $$, 其他參數同步驟 5$$ empty key, empty associated Data, same version $$. 8 字節結果 $ T $ 被編碼在二維碼中。在解密時，比較決定我們是否接受具有給定密碼的二維碼。該比較不需要側通道保護，但如果它失敗，除了錯誤指示之外什麼都不能輸出。
安全論據：
- Argon2 的輸出在計算上與隨機無法區分，除非密碼被猜測；因此 $ C $ 沒有洩漏 $ \text{seed} $ .
- 完整性測試使用 $ T $ 在功能上是一個由步驟 5 的主 Argon2 的輸出鍵控的MAC ；這就是為什麼額外的 Argon2 可以很快的原因。
- 我們使用 Argon2i 來保證完整性，因為它承諾最大的側通道電阻和鍵拉伸$$ which the other forms optimize $$不是一個目標。
- 刪除 AES 使測試密碼片語變得稍微容易一些，因為與步驟 5 的主要 Argon2 相比，AES 解密的計算負擔可以忽略不計。 $ \text{seed} $ 作為正常解密方式的候選者，額外的 Argon2 在成本上可以說與 AES-GCM 相當。與其他可能的 aes 測試相比，AES 解密的成本通常較低 $ \text{seed} $ 候選人（例如針對公鑰或簽名對其進行測試）。
在 $ \text{salt} $ 大小（B/C），主要目標 $ \text{salt} $ 是
- 當對手攻擊許多二維碼並滿足於破壞任何二維碼時$$ rather than one or few in particular $$, $ \text{salt} $ 防止 QR 碼可能發生的字典攻擊的預期工作減少（僅兩倍） $ \text{salt} $ 碰撞。
- 在獲取 QR 碼之前預先計算 Argon2 輸出 [例如建構彩虹表] 是徒勞的$$ for a faster attack, or leveraging resources otherwise not available $$.
建議的 12 個字節用於 $ \text{salt} $ 從兩個角度來看都很好：如果我們假設 $ 2^{40} $ 二維碼，大約有一次機會 $ 2^{12\cdot8-2\cdot40+1} $ （130,000 分之一）第一個項目符號適用。除了密碼片語和 Argon2 參數太弱以至於它們沒有提供有用的保護之外，第二個是沒有問題的。事實上，從一個特定使用者的角度來看，6 字節 $ \text{salt} $ 只要密碼不被大量重複使用就足夠了。
關於使用 $ \text{salt} $ 作為 AES (D) 的 IV：只要兩者沒有衝突，這不是問題 $ \text{salt} $ 和密碼
$$ because Argon2 makes no use of AES, hence the identity quickly dissipates $$. 如果兩者發生碰撞 $ \text{salt} $ 和密碼，AES-GCM 和這個答案的提議都有同樣的問題：洩漏 $ \text{seed} $ 編碼在一個二維碼洩漏 $ \text{seed} $ 在另一個。這是 AES-CBC 具有優勢的一個領域 [因為前 16 個字節的差異 $ \text{seed} $ 可能會挽救這一天]。
GCM 有消息認證。但我不認為延展性是一種攻擊媒介。
AES-GCM 與 AES-CTR 一樣加密（IV 中的偏移量為 1 除外），但增加了身份驗證。在最初的提議中，GCM 身份驗證至少有一個重要功能：它在解密時發現使用錯誤的密碼。取決於什麼 $ \text{seed} $ 用於，解密中的延展性很可能是攻擊向量。沒有聲稱 ECDSA 能夠抵抗攻擊者可以竊取密鑰位的攻擊環境。
注意：如果能夠編碼任意 $ \text{seed} $ 不需要，我們可以設置 $ \text{seed}\gets K_0 $ 並保存 32 個字節 $ C $
$$ since it’s all-zero $$. 這不會改變知道 QR 碼的對手的安全性。如果我們想要額外保護不知道 QR 碼的對手（這是非常合理的），我們可以重命名 $ \text{salt} $ 二維碼欄位 $ \text{pepper} $ $$ to denote that it’s secret to a degree $$, 並將其大小增加到 24 字節$$ which combined with the entropy in the passphrase and the Argon2 key stretching is more than overkill $$.