我有一個設計問題。我有一個使用.NET加密API來加密/解密數據的Web應用程序。 （應用程序使用舊的加密算法，如MD5和SHA-1）。此外，應用程序對生產代碼中的加密密鑰進行硬編碼。加密敏捷性和密鑰管理
我想; 1）將現有的舊算法（MD5和SHA-1）更新爲新的算法。 2）將加密密鑰從源代碼移至安全共享。 3）可以方便地更換加密密鑰
我的設計;
算法更新 對於算法更新，我們使用特定的.NET加密算法實現。我們使用類似MD5CryptoProvider或RijndaelManaged的類。這些都是硬編碼的。我將刪除特定的算法依賴關係，並使其更加靈活;
HashAlgorithm algo = HashAlgorithm.Create（MyPreferredHash.ToString（））; algo.ComputeHash（...）;
MyPreferredHash值將從配置文件中加載，以便我們可以在需要時進行更改。
問題：升級代碼很容易。但是，您是否看到更改密碼算法的任何潛在問題？我們不會在任何地方存儲任何加密或散列數據，並且Web應用程序是無狀態的。所有的哈希值都會生成並附加到url字符串並從其他頁面解密。因此，不存儲數據。除了cookies。當我們加密cookie並將其發回給用戶時，我們會在服務器收到它時解密它。在這種情況下，我想到銷燬cookie並向客戶發送一個新的cookie。這是否合理？您認爲的其他任何問題？
密鑰管理設計的
第二部分，是從源代碼中刪除硬編碼密鑰來保護共享。在此之後，我需要能夠推出新的加密密鑰。每個加密密鑰都將與過期日期相關聯。當我們推出一個新的加密密鑰時，新的密鑰將用於加密和解密。如果它解密失敗，那麼我們可以嘗試舊的密鑰。舊密鑰將用於解密或驗證，直到其過期日期。當他們過期時，他們應該退休。
用於存儲;我正在考慮將加密密鑰存儲在本地計算機的配置文件中，作爲將通過安全共享駐留的主密鑰「加密」。因此，任何無權訪問此安全共享的人都將無法看到主密鑰。當機器重新啓動時，主密鑰將從安全共享加載到機器註冊表中。本地機器中的加密密鑰將從配置文件（本地）加載並通過註冊表中的主密鑰進行解密。
此存儲選擇將使我們只能在安全共享中存儲一個主密鑰，並且還會對加密密鑰進行歷史更改，因爲我們會將它們存儲在版本控制系統中。
具有挑戰性的部分是關鍵的變化/更新。
對於分佈式Web應用程序，這裏推薦的密鑰更改算法是什麼？如果我們在發佈後進行部分部署，並非所有機器都具有相同的配置文件內容（例如添加了新的加密密鑰）。所有站點部署可能需要1-2周。這也是另一個問題，如果我們應該等待所有部署完成，以便這些密鑰在那之後生效。
其他意見嗎？