如何安全地儲存數據？/ 如何安全地加密文件？

如何安全地加密文件？

或以不同的方式表述：

如何安全地將應用程序的數據儲存在文件中？

注意：使用已建立的工具不是一個選項。這些任務需要在程序級別完成（使用庫等）。

1. 問問自己是否可以安全地儲存使用者的數據。

這包括檢查使用者是否不會被 root / admin 使用者嗅探。
還要確保您的實施是安全的。
採用標準程式碼審查機制，確保您的實現具有針對定時攻擊的對策（例如針對 AES）。
還要確保使用適當的數據類型。
使用使用 malloc 分配的 byte* 通常不是很安全。如果您的庫提供數據儲存機制，請使用它們！
您的作業系統還可能提供在記憶體中保護數據的方法，例如 Windows 中的數據保護 API 僅依賴於目前使用者，可用於隱藏記憶體中的敏感密鑰。閱讀 Schneier 的 Cryptography Engineering 對您來說可能是一個非常好的主意，以確保您沒有側通道洩漏。 2. 問問自己可以使用什麼來****驗證使用者。選項是（明確允許並建議在方便和可用性允許的情況下將它們 組合起來）：

1. 密碼：您的使用者可以提供密碼或密碼。不要限制他的長度，讓他使用好的和長的密碼。這通常是一個不錯的選擇，因為它需要使用者知道一些東西，因此不會像 USB 棒一樣失去。

2. 密鑰文件：允許使用者提供密鑰文件。這些文件可能看起來很隨意，但應該很少見。允許使用者使用應用程序的（加密）隨機數生成器來生成強密鑰文件（長度為 64 字節或更多）。密鑰文件的範例是稀有文件，例如個人（word/）文本文件或僅包含隨機數據（使用應用程序的隨機數生成器創建）的故意生成的文件。

3. 定制硬體：如果您正在大規模部署，您可以強制要求使用者使用防篡改硬體設備。此設備應支持使用設備持有的密鑰進行對稱加密。

4. 使用者硬體：允許使用者使用他的PKCS#11或類似的智能卡或提供公鑰加密的加密令牌來使用。還允許使用者使用TPM保護密鑰（如果可用）

5. 作業系統數據：允許使用者根據目前作業系統中儲存的內容進行解密，例如使用者憑據或作業系統提供的安全密鑰儲存。

6. 檢查您可以使用的算法。您將需要（在最壞的情況下）五類算法：基於密碼的密鑰派生函式、加密算法、操作模式、消息身份驗證程式碼和加密安全隨機數生成器。
   在撰寫本文時，推薦使用以下算法（按降序排列）。如果已經提供了更多頂級功能，請不要使用它。

7. 加密安全的隨機數生成器：

   1. 財富
   2. 經批准的算法。這可能是競賽的結果，也可能是某個受信任的機構（例如ANSSI、NIST、BSI等）認可的算法。避免由研究所提供參數的具有“可證明”安全性的算法，這些參數可能會被故意選擇以獲得後門訪問。對於播種，請使用****作業系統的加密安全隨機數生成器。它們通常有點隱藏。
   3. 一些“弱”的標準方法。（即在CTR 模式下執行塊密碼並儘快刪除密鑰和 IV）從作業系統 的加密安全隨機數生成器中獲取密鑰和 IV。它們通常有點隱藏。

8. 基於密碼的密鑰派生函式：

   1. PHC 競賽的獲勝者。如果有多個獲勝者，請詢問差異並使用最適合您需求的那個。
   2. 加密
   3. bcrypt
   4. PBKDF2，使用高效且安全的散列函式（在您的平台上）
   5. 實現你自己的 PBKDF2！

9. 密碼：

   1. CAESAR競賽（2018 年以上）的獲勝者。如果有多個獲勝者，請詢問差異並選擇合適的一個。
   2. AES。注意：對於 2070 或更早版本需要保密的數據，建議使用 AES-128。在所有其他情況下，請使用 AES-192 或 AES-256。
   3. ChaCha（首選）或Salsa20。
   4. 以下三項之一：三魚、蛇或雙魚
   5. 具有 3 個密鑰的3DES 。（需要 168 位密鑰材料）

10. 操作模式（CAESAR 獲獎者已過時）：

    1. OCB（如果專利已過期）
    2. GCM
    3. EAX（首選）或CCM
    4. CTR，在此下方需要一個消息驗證碼（包括）
    5. 以下之一：CFB 或 OFB
    6. ECB，不惜一切代價避免，而是實施自己的點擊率！

11. 消息驗證碼：

    1. Poly-1305採用標準化結構
    2. HMAC，使用安全的標準化散列函式，最好 是SHA-3或SHA-2系列的成員。先加密數據，再驗證密文！
    3. 實現你自己的 HMAC！

12. 問問自己如何設計頁眉。標題應包含：

• salt，一個隨機的64 字節或更多值，將在每次創建新文件時新選擇。這將被輸入到基於密碼的密鑰派生函式中。salt 可以是open，但可以使用身份驗證機制進行身份驗證。
• 基於密碼的密鑰派生函式的參數。這些參數需要打開。應該選擇它們，以便在目標平台上密鑰派生需要大約**100 毫秒到 1 秒。**指示所使用的基於密碼的密鑰導出函式的值被視為參數。
• 密碼/模式的隨機數或 IV。該值應隨機選擇並公開儲存。
• 標頭的其餘部分應加密和驗證。
  前面提到的 nonce/IV 應該與使用基於密碼的密鑰派生函式和儲存的鹽和參數從密碼派生的密鑰一起使用。
• 文件數據部分的主密鑰。這些應該是隨機的和最大的長度。這是標頭的加密部分的一部分
• 數據部分的隨機數/IV。這個值應該是隨機的。該值可以（並且應該）是標頭的加密部分的一部分。

5. 實際數據現在使用上面選擇的密碼/模式/身份驗證三元組和標頭的加密部分的密鑰/IV/nonce 對進行加密。

現在可能會出現一些問題：

1. 使用多重加密是否值得？
   不會。由於中間相遇攻擊，雙重加密的好處只有1
   位。流密碼可能更容易組合，但絕對沒有必要，因為在可預見的未來（50 年以上）內所有密碼都是牢不可破的
2. 我應該使用哪些身份驗證方法？
   盡可能多，但至少要密碼
   您需要有一個很好的理由不使用密碼，因為其他所有內容都可能受到管理員權限的攻擊或被盜。
3. 您沒有在標題部分提到其他四種身份驗證方法，我應該如何合併它們？
4. 密鑰文件：假設每個密鑰文件具有低熵。話雖這麼說，你真的不能對它做很多事情。使用一些摘要擴展函式和您最喜歡的安全散列函式 (SHA-2/3) 從每個密鑰文件中派生一個密鑰，並構造一個由所有文件的散列和使用者密碼組成的大 XOR。這看起來像這樣： $ Key = PBKDF(PW) \oplus H (File_1) \oplus H(File_2) \oplus … $ ， 在哪裡 $ \oplus $ 表示按位異或。
5. 自定義硬體：在創建文件時，讓設備生成一個對稱密鑰，該密鑰將保存在設備內部。執行直到密鑰文件/密碼級別的所有操作（直接參見上文），然後將其發送到設備進行加密。每個文件使用的密鑰不必是唯一的。建議對所有文件使用一個密鑰。也可以將標識符添加到文件中以辨識關聯的硬體密鑰。
6. 使用者硬體：讓設備生成一個 OpenPGP 密鑰或一個有效的 S/MIME 加密證書。將作為上述步驟（或上述 2 個步驟）的結果的密鑰發送到設備進行解密。它將解密它並返回用於解密主密鑰的密鑰。
7. 作業系統數據：如果您有使用者憑據（可能是一些隨機字元串），請將它們散列並以與密鑰文件相同的方式同時合併它們。如果您的作業系統為您提供安全儲存（或您的 TPM 提供），請儲存一個密鑰並將其作為“密鑰文件”傳遞，從而對其進行雜湊處理並將其合併到 XOR 步驟中。
8. 我應該使用開源庫還是一些閉源庫？
   開源
   機會很大，在知名的開源庫中沒有任何安全問題，而封閉源則限制了您何時可以使用它，通常您必須付費才能使用並且您通常無法自行檢查程式碼以確保其安全。
9. 為什麼使用 XOR 來包含密鑰文件？（與問題 3 有關）
   方便。
   如果你不使用可交換的東西，比如 XOR，使用者會遇到問題，因為文件必須以完全相同的順序提供。如果只是重新命名文件但保留其內容，這將變得更加困難。從安全的角度來看，這同樣不安全，因為一個基本上建構了一個“流密碼”，其中包含基於密碼的密鑰派生函式輸出、密鑰文件的雜湊值和其他輸出（TPM、憑據等），它是安全的只要一個來源是安全的。

引用自：https://crypto.stackexchange.com/questions/25695