2010-06-24 111 views
1

我在想,如果有可能和/或可行的混淆和安全來做爲後續:C#公鑰驗證Perl私鑰並用作AES密鑰?可能和/或可行?

  • 與服務器客戶端啓動會話(這意味着一個有效的登錄名和密碼已發送和接受)
  • 服務器使用私鑰對隨機密碼進行加密,然後將其用於使用Rijndael方法的數據加密,並將兩者都發送回客戶端(密碼是加密的隨機密碼和Rijndael的加密數據,這正是我們想要的客戶端工作)
  • 客戶端將收到兩個,驗證密碼,看看它是用我們的一對密鑰加密或不如果是的話,它將被用來解密數據。

從我看到的情況來看,Rijndael對密碼大小有一些限制,所以這甚至可能(考慮加密隨機密碼的輸出)?

是否有一些與我在想或想要描述的東西接近的antoher approuch?

這是甚至有點w?嗎?

我想要這樣的東西的原因主要是爲了讓任何人都難以重現我們的服務器與客戶端通信的情況,除此之外我們還使用智能裝配。我希望你們把重點放在上面的問題上,忘記包裝我的代碼等。如果可能的話,可以把它看作是客戶端/服務器通信安全的信息。

此致敬禮。

回答

1

我可以解決第一部分。如果服務器使用其私鑰對密鑰進行加密,那麼ANYONE及其公鑰將能夠對其進行解密。這爲一箇中間人攻擊留下了一個空洞。換句話說,如果我攔截你所做的同樣的道理,我現在知道你知道的同一把鑰匙。這意味着我可以看到所有來回的流量。

安全的癥結一直是這個最初的密鑰交換問題。您可能需要採用行業標準方法,如Diffie-Helman進行實際的密鑰交換。希望有所幫助

+0

@Rob嗨,我可能會說錯了什麼或弄錯了,我的服務器私鑰的含義是使用我的PERL代碼我已經生成了一對私鑰和公鑰,這些私鑰和公鑰都是默認設置的要在我的客戶端和服務器上使用(使用給定的私鑰,我正在生成一個加密的隨機密碼),甚至有可能攔截SSL數據,它是通過https請求發送所有這些數據的地方?如果我說了些奇怪的話,請糾正我,否則我可能會誤解你。 – Prix 2010-06-24 06:47:37

+0

@Prix - 在這種情況下,您所描述的基本上是SSL已經做了什麼。換言之,當您建立SSL連接時,雙方的公鑰/私鑰只用於協商要使用的對稱密鑰。所有其他流量均採用對稱算法加密發送。 首先,如果您已經在使用SSL,我認爲您不需要擔心這一點。不,我不知道有任何打破SSL的實用方法。如果有的話,我們不能再去網上銀行/信用卡公司了!我認爲SSL單獨處理你想要的東西 - 對嗎? – 2010-06-24 07:02:25

+1

另一個想法 - 如果你想要的只是晦澀難懂,你可以base64編碼數據,你可以使用二進制序列化,你可以使用壓縮algortihm等。我想這一切都取決於你真正需要多少安全。 – 2010-06-24 07:04:58