幾年前，當第一次被引入到ASP.net和.NET Framework時，我構建了一個非常簡單的在線文件存儲系統。 該系統使用Rijndael加密來存儲服務器硬盤上加密的文件，並使用HttpHandler解密並將這些文件發送給客戶端。AES加密和密鑰存儲？
作爲我的第一個使用ASP.net和數據庫的項目之一，我並不十分了解整個系統是如何工作的（以及落入same trap described by Jeff Atwood on this subject），所以我決定將新生成的密鑰和IV與每個文件項在數據庫中。
爲了使事情更清楚一點，加密只是爲了防止文件直接訪問服務器，並且密鑰不是由用戶輸入的密碼生成的。
我的問題是，假設我不希望保留的所有文件的一個關鍵，如何應該我存儲加密密鑰爲安全起見？什麼被認爲是最佳實踐？ （即：在不同的服務器上，在純文本文件上加密）。
此外，這種類型的加密算法中使用的初始化向量是什麼？它應該在系統中保持不變嗎？
鑰匙應該受到保護並保密，就這麼簡單。實施不是。密鑰管理系統通過值得信賴的供應商大量出售，因爲解決問題的辦法是hard。
你肯定不想爲每個用戶使用相同的密鑰，使用的密鑰越多，破解它的「更容易」，或至少有一些信息泄漏。 AES是分組密碼，它將數據分成塊並將最後一次塊加密的結果輸入到下一個塊中。初始化向量是算法的初始入口，因爲在起始點沒有任何開始。使用具有相同密鑰的隨機IV可以降低信息泄露的風險 - 對於加密的每一個數據應該是不同的。
存儲密鑰的方式取決於系統的架構。我剛剛完成了一個KMS，其中的密鑰遠離主系統，加密和解密的功能通過WCF公開。您發送純文本並獲得對密鑰和加密文本的引用 - 這樣KMS就負責系統中的所有加密。這可能在你的情況下是矯枉過正的。如果用戶在您的系統中輸入密碼，那麼您可以使用它來生成密鑰對。然後可以使用該密鑰對該用戶的密鑰存儲進行加密 - XML，SQL等，並用於解密用於保護數據的每個密鑰。
不知道更多關於如何配置系統的信息，或者目的很難推薦除「密鑰必須被保護，密鑰和IV不能重複使用」以外的任何其他信息。
作爲一個很好的soltution，你可以存儲你的密鑰/ IV對一個表：
ID Key IV
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923==
當您保存加密值，保存ID，並與它一起隨機鹽值。
然後，當您需要解密該值時，使用id和鹽與數據一起存儲來查找key/iv對。
你想確保你的密鑰存儲周圍有一個很好的安全模型。如果使用SQL服務器，請不要將SELECT權限授予從應用程序訪問數據庫的用戶。你不想讓某人訪問整個桌子。
如果您將SQL服務器本身定義爲固有安全並將密鑰存儲在其中以滿足您的安全需求，那麼這是一個非常好的解決方案。這可以通過在sql server上啓用透明數據加密來進一步消除，以防止有人將DB從服務器複製出去，或物理上讓硬盤繞過所有軟件訪問控制。 – 2010-01-11 15:36:05
在http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html上有一篇非常好的文章，其中涵蓋了IV和鹽析問題以及上述ECB的問題。
它仍然沒有完全覆蓋「我在哪裏存儲密鑰」，無可否認，但閱讀和消化之後，它不會是一個巨大的飛躍，希望能解決....
已損壞的文章鏈接 – CodeClimber 2013-08-01 15:12:00
2年前的答案和我無法控制的域名。時間使用互聯網存檔Wayback機器.... – 2013-08-05 12:09:40
對於懶惰的 - http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html – 2013-08-05 13:55:42
次要觀察：「AES是一個分組密碼，它將數據分成塊並將最後一個塊加密的結果送入下一個塊。」您正在描述[CBC]（https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29）* a *安全使用AES的方法。還有其他安全的解決方案 - 並不都需要一個初始化向量。 – KovBal 2014-10-14 16:55:39