我有一個客戶端 - 服務器結構，並且爲了避免發送我正在考慮使用固定密鑰的公鑰。那這個呢？修復非對稱RSA加密中公鑰和私鑰的值是否不安全？
我是填充和加密時使用隨機SHA-256。所以，在公衆固定的情況下，攻擊者不能用暴力破解。
我有一個客戶端（Xamarin APP）和一個Web Api服務器。我已經在使用SSL，我知道這足夠了！但想象我不能使用SSL，我必須使用異步加密。我必須：CLIENT-請求publickey - > SERVER - 生成公鑰和私鑰 - > CLIENT - 獲取publickey和cripto，發送cripto數據 - > SERVER - 獲取cripto數據並解密。
這取決於您是否擁有對客戶端和服務器的控制權，如何存儲/修復密鑰以及將替代品部署到客戶端/服務器代碼的難度。如果重新部署並不困難，並且您知道客戶端的所有實例都會立即更新，那麼我認爲如果您需要旋轉密鑰，您可以重新部署。
但是，如果對您進行重新部署並不容易，或者您不能保證所有的代碼都會被及時更新，這可能是一個問題，因爲您可能沒有辦法旋轉鑰匙，如果你目前的鑰匙被盜用了。
另一個問題是，你並不是真的想讓所有的客戶端都使用相同的私鑰，特別是如果你有很多客戶端。這增加了您的私鑰最終被泄露的風險，並且使服務器更難以驗證各個客戶的真實性。此外，這會造成單點故障，因爲如果私鑰被泄露，則會損害客戶端的所有的通信。如果每個客戶都有自己的私鑰/公鑰，如果其私鑰受到攻擊，則不會對其他客戶產生影響，因此受到的損害將更加嚴重。
使用每個客戶端密鑰時，泄露私鑰只會危害自上次密鑰輪換以來發生的單個客戶端的通信;例如，如果您每3個月輪換一次密鑰，那麼一個密鑰永遠不會損害單個客戶端的超過3個月的通信。 （平均而言，這會損害該特定客戶的1.5個月通信）。順便說一下，也許我錯誤地理解了你的問題，但公鑰密碼學公鑰並不重要，只是你有辦法保護私鑰。爲了安全存儲私鑰，.NET Framework確實有key containers。
@zaph我的意思是，如果客戶使用同一個私鑰，我可能會誤解他的問題，但我假設他將硬編碼服務器和客戶端的公鑰/私鑰。 – EJoshuaS
@zaph這絕對有可能是我誤解了OP在這裏做什麼，我的假設是，客戶端和服務器都有單獨的公鑰/私鑰對，並且它們都是硬編碼的（即每個客戶端都使用相同的硬編碼公/私鑰對），糾正我，如果這是錯誤的。如果我的理解是正確的，肯定會有安全風險。 – EJoshuaS
@zaph我同意，事實是有很多客戶端並不會破壞服務器的私鑰 - 但是，如果所有的客戶端都有相同的私鑰，那將會是一個問題，因爲它會使得它變得更加困難爲服務器驗證客戶端，增加密鑰泄露的可能性，並增加密鑰泄露的影響。 – EJoshuaS
在客戶端應用程序中嵌入公鑰應該很好，很安全。
這假設公共/私人密鑰對在創建應用程序時創建一次，公鑰已嵌入到應用程序中並且私鑰保存在服務器上。
有趣的是，我在網上沒有發現任何關於此的討論。你有一些文章或網站在談論這個？ –
通常的方法是使用HTTPS。使用HTTPS將公鑰以證書的形式發送給客戶端。這允許客戶端能夠聯繫任何服務器而不需要預共享公鑰。在你的情況下，你只是預先共享公鑰。 – zaph
如果您可以保護客戶端的完整性，則使用固定的公鑰更安全，而不是從空想起引導安全連接。
閱讀了很多問題和評論，聽起來好像你想阻止一箇中間人解密從客戶端到服務器的消息。爲了做到這一點，客戶端必須確保使用服務器的公鑰，而不會被欺騙使用中間人生成的公鑰。
如果在客戶端中嵌入了公鑰，並且您有一些機制來確保密鑰是真實的，那麼您是安全的。
在基於PKI的應用程序中，這是通過使用由知名CA頒發的證書並在使用前驗證它們來完成的。在自制程序中，您可以計算客戶端應用程序的散列值，將其安全地傳輸到客戶端（在通過HTTPS提供的下載頁面上，通過電話或由受信任方編寫的代碼等），並驗證下載的應用程序在運行之前，哈希匹配真正的散列。
我不得不同意@zaph在這裏，這絕對是一個重要的說明。你還可以澄清一下你正在考慮存儲私鑰的機制，並在必要時旋轉它/它們嗎？ – EJoshuaS