我有一個將加密文件存儲到磁盤的Windows窗體應用程序。在運行時，它解密這些文件並將生成的內存流傳遞給數據集。我正在使用AESManaged進行對稱加密。安全地存儲用於生成對稱加密密鑰的字符串
有一些自定義函數可以從字符串生成Key和IV字節數組。然而，我目前正在對我用來生成Key和Iv的安全字符串進行硬編碼，我認爲這會破壞加密的目的。我知道最好的方法是提示用戶輸入密碼並使用該字符串。有沒有其他解決方法，我不需要提示用戶輸入密碼？另外，我無法使用DPAPI，因爲預計會在用戶和計算機之間共享加密的數據文件。
這是不可能有你的蛋糕，也吃了它:)你不能存儲解密密鑰和使用它，並沒有讓人可以恢復。只有通過混淆代碼，加密密鑰並動態解密纔可以做到這一點，也許可以通過圍繞幾個類的多輪解密來實現。與其他編程學科不同，這是凌亂的代碼是一件好事。
我認爲你還是應該考慮DPAPI;不用於加密數據文件，而是用於加密祕密字符串。
有沒有可能要問你的用戶只需一次輸入所述祕密串*如果你能，你會則：
由於您的數據文件仍然會被AES以相同的祕密字符串加密，所以它們仍然可以互換。 （在具有相同祕密字符串的人羣中...所以現在你已經創建了它，以便您的應用可以擁有多個安全羣組，每個羣組都設置自己的祕密......但這是一條切線。）
優勢即使有人得到你的代碼，也沒有任何逆向工程會回饋祕密字符串。因爲它不在那裏。
請注意，這比單獨使用混淆更好。通過模糊處理，如果攻擊者獲得了代碼並可以在自己的環境中運行代碼，則他們可以附加一個調試器，並在將該字符串傳遞給AES代碼時停止。他們不必關心你使用多少技巧來爭奪它。他們在解讀完之後纔會觀看它。使用DPAPI，除非他們在用戶的上下文中運行您的代碼，否則無法工作......在這種情況下，無論如何遊戲。
我不是說DPAPI是完美的，但在這種情況下，我會真正考慮它，然後再訴諸單獨的混淆。 （您仍然可以通過模糊處理工具運行您的代碼：這也是一件好事，僅僅是不夠）。
*如果不是，您可以在安裝/初始配置時提供嗎？我已經在文件中看到了一些以純文本形式安裝密鑰的地方，然後程序會在首次使用時對其進行加密。