流密碼檔案加密

檔案加密不同於實時通訊加密在速度上要求不高，所以金鑰陣列可以做得更強大一些，這也就避免了什麼流密碼金鑰混亂程度不夠的偏見，要想資訊保安金鑰陣列要做到唯一性，獨一無二的金鑰陣列只能用一次，這樣就避免了已知明文攻擊的陰影。但是如果使用者使用了相同的密碼，如果生成金鑰的方法固定仍然可以形成相同的金鑰陣列，這可以用一下兩種方法解決：1）讓加密軟體自己生成使用者密碼，這樣可以產生出隨機性很強的使用者密碼，幾乎沒有重複的可能性；2）使用加鹽（selt）技術，程式使用一些隨機數作為使用者密碼的一部分，鹽是需要妥善儲存的，此時即使使用了相同的使用者密碼關係也不大了，這樣也能解決使用者使用相同密碼的問題。

接下來是建造金鑰陣列，金鑰陣列的建造是在使用者密碼的影響下建造的，加密和解密時要使用同樣的金鑰陣列才能讓加密的資訊復原如初，最好的辦法是構造出乙個金鑰陣列，根據明文的長度建造同樣規模的金鑰陣列，已完成一一對應的加密和解密工作，金鑰陣列的長度有了，首先在陣列中放置元素，所有用到的元素盡可能均勻地放在陣列中，最初它們可以是順序排列的，這樣比較好處理，然後對這個陣列進行隨機排序以打亂原來的秩序，可以借助於優良的隨機函式來完成排序，例如做乙個迴圈來處理，先根據使用者密碼的計算值做成隨機函式種子，陣列的長度為迴圈變數，第乙個陣列成員和隨機函式算出的陣列長度範圍內的乙個值作為序號的陣列成員進行資料交換，然後是第二個陣列成員，餘此類推到迴圈結束，這樣所有的陣列成員都被交換了，形成了新的陣列，這樣就完成了一次隨機排序，必要時可以進行多次。根據筆者的經驗如果陣列長度超過所有元素總和的數倍以上陣列才容易分布均勻，當金鑰陣列的尺寸較小時（例如小於元素總和數），初始陣列應大於元素總和數的數倍，完成隨機排序後再擷取需要的長度以保證均勻分布，金鑰陣列很大時就無此必要了。例如位元組陣列有256個元素，實測用1m的位元組陣列可以通過nist標準全部15項檢測，說明建造的陣列是不錯的。注意使用者密碼不可過短，過短容易被跟蹤破解，極端的例子就 1位乙個數做密碼，很容易就被攻克，所以一般要設定使用者密碼個數的下限，但自動加鹽的設計是不怕密碼過於簡單的。

這樣造出的金鑰是很難仿造的，對外來說，每個使用者密碼位元組都是未知數，並且每個明文位元組和金鑰位元組都是未知數，未知數的總和大於能夠開列的方程數許多倍，從方程論的角度也是不可破解的。

有了金鑰陣列，對明文的加密就簡單了，推薦使用加法作加密減法做解密，而不要用異或來做，後者的計算缺乏靈活性，例如連續多遍加密異或就不行了。明文位元組依次和金鑰位元組做加法（無符號運算）得到密文位元組，解密時密文位元組和金鑰位元組做減法（無符號運算）就還原出明文位元組了。明文或密文陣列和金鑰陣列的結合方式可以是多種多樣的，讓使用者密碼來控制選用何種方式將造成豐富多彩的格局，使加密強度提高。

有人認為用窮舉攻擊可以解密所有的加密，這是一種謬見，而能讓其得逞的正是加密軟體本身，有些加密軟體為了人性化設計成這樣：當做解密操作時，如果密碼錯誤軟體將告訴你密碼錯誤，這樣破解者就可以編制乙個軟體展開窮舉攻擊，那個加密軟體就淪落成乙個錯誤密碼篩選器成為破解自己密文的**。如果人性化設計對資訊保安造成損害那麼不要也罷。正確的方法是：可以做少量密碼正誤的檢測，但即使通過檢測也不一定能完成解密，只有正確的密碼才能完成解密，這樣就不是完全出賣了自己，也實現了人性化設計。或者完全不做檢測，這樣雖少些人情味但安全性是最好的，自己加密的東西解密後是什麼自己最清楚，密碼輸入錯誤自己再輸入唄，用不著軟體來提醒你。

上面看到自己做金鑰陣列雖然也很省事但實際上有沒有必要？現實中許多隨機函式就能生成隨機性很好能通過nist檢測的陣列，這些東西不能做金鑰嗎？答案是肯定的，儘管生成的資料之間有內在的連帶關係，但由於它們只出現在計算過程中，你儘管知道用了什麼函式，怎麼用的想讓這些資訊對破解密文有所貢獻是完全不可能的，因為其特徵被其它資料淹沒了。一旦破解者沒有了軟體提供的判斷依據，他仍可以實行窮舉攻擊但是困難多多，他仍可以組織大量的偽使用者密碼給加密軟體而得出偽明文，但想從中找出正解是太難了，因為各種形式的解是等概率的，你可能得到可以讀懂但完全矛盾的解，這時你將無法判斷誰是正解。如果明文本身就是亂碼的話，那你的出路只有絕望了。

嚴格的遵守規則加密軟體不留漏洞不可破解就是常態，而破解才是奇蹟。

流密碼檔案加密

20151116 密碼檔案

oracle密碼檔案

oracle密碼檔案

流密碼檔案加密

20151116 密碼檔案

oracle密碼檔案

oracle密碼檔案

相關推薦