基於驅動器中字節的密鑰生成算法
我是一名新手網路安全學生，並想出了一種生成隨機加密密鑰的方法。
該算法的工作原理如下：
- 獲取目錄中每個文件的大小（以字節為單位）（深入每個文件夾以僅獲取文件）
- 將每個字節大小連接在一起，例如：2 字節的文件長度和 4 字節的文件長度將使“24”
- 這會創建一個數千位數的字元串（我已經完成了長達 10,000,000 位數的操作）
- 如果使用者需要一個超長的密鑰，請使用 SHA-256 散列每個單獨的字元
- 將最終的字元串（數百萬字節）散列為兩個 64 字節的散列，然後根據使用者選擇將它們組合成 128 字節或 256 字節。
我選擇這種方法的一些原因包括創建的字元串的隨機化，因為兩個人不太可能擁有完全相同的驅動器結構，並且由於大多數文件都是幾百字節或更多的。
我想這不是一個非常直接的問題，但是這個算法聽起來有用/安全嗎？有什麼方法可以改進這個算法？
有用：否。 安全：否。
您的問題中最相關的部分是標題，我對“基於驅動器中文件長度的密鑰生成算法”稍作糾正。正是在這裡，您一開始就做出了無效的假設。不過，後來也有其他人。
隨機加密密鑰本質上是熵，您可以將其解讀為不確定性。所以從高層次上看，關鍵=熵=不確定性。典型機器上的文件結構相當明確，無論是正確的 *nix 機器還是其他機器之一。如果機器是新創建的（尤其是作為虛擬映像或嵌入式），則機器實例之間的文件佈局可能相同。因此，從文件系統派生的任何密鑰（其長度或內容）都將是高度可預測的。那裡是不安全的。你混淆了複雜性和不確定性。文件系統當然很複雜，但想想所有那些免費的AOL最終成為杯墊的 CD。如果您在新安裝的 AOL 目錄中執行算法，則所有生成的密鑰在您剛剛安裝的任何機器上都是相同的。你們所有的 1000 萬個數字連接都是相同的，或者幾乎是相同的。
第二個錯誤是密鑰長度。作為一名安全學生，您會遇到典型的可接受的密鑰大小。甚至沒有人需要超過 256 位的密鑰安全性。這個極限有數學證明。您創建超長密鑰的嘗試毫無意義。許多密碼原語都是圍繞 256 位大小設計的。您試圖使用 1000 萬字節的密鑰做什麼，因為沒有合法的功能來吸收這樣的密鑰？
$$ You’re not thinking one time pad are you? $$ 恕我直言，基於這個問題，您可能對密碼學很陌生。如果不對密碼密鑰的性質及其與熵的關係有更廣泛的了解，就無法對該算法進行有效的改進。
儘管您最終正確地意識到可以從現代電腦環境中的混亂攪動中生成密鑰。混沌原理可以應用於文件系統，並且存在真正的熵，但在安全地提取它之前，需要對這些原理有更深入的了解。