非對稱密鑰切換的對稱密鑰

我不是密碼學專家，實際上我只有一點點經驗。無論如何，時間已經到了，我的一個應用程序要求我設置一些加密。請注意，該計劃將不會管理任何超級關鍵任務，這將會造成很大的損失。無論如何，我只是試圖看看我使用的這個方案是否普遍，如果有缺陷（其中可能有完全愚蠢的設計，這就是我要問的原因）。非對稱密鑰切換的對稱密鑰

好吧，我有一個客戶端 - >服務器通信。客戶端可以在2048位RSA密鑰的公共部分中進行硬編碼。當客戶端想要發起安全連接時，他會發送他的用戶名，密碼的md5哈希以及隨機UUID的散列，所有這些散列都已根據服務器的公鑰加密。服務器接收信息並使用其私鑰解密。檢查數據庫以查看他的登錄+傳遞是否工作&，如果他們這樣做，則在數據庫的「Sessions」表中創建一個新條目。這包括SessionID，UID（用戶ID）和UUID哈希。使用相應的會話ID的UUID作爲關鍵字，服務器將發回一條消息，其中包含Blowfish加密的單詞「Success！」。 +隨機的UUID（這個消息是數字簽名的，所以我們可以確定它是否來自服務器）。從那時起，當客戶端向服務器發送信息時，它將以明文sess_id &包含Blowfish加密消息，並使用相應的會話ID的blowfish密碼（在DB中加密存儲）作爲加密/解密密鑰。

具體而言，我很好奇這個系統是否「應該工作」，或者是否有人注意到明顯存在漏洞，比如MITM。

來源

2010-02-08 Crowe T. Robot

難道你不是在重塑SSL嗎？ – 2010-02-08 15:42:25

的問題，我可以看到我的頭頂部（雖然你已經離開了大部分的細節，這就是魔鬼著名所在）：

如果您使用的是UUID生成相當而不是一個真正的密碼RNG，它可能沒有足夠的熵。不要打折 - 在現實世界中，祕密削弱加密系統的最佳方式是削弱RNG;
您的初始RSA加密聽起來像是容易受到小指數攻擊以及潛在的其他創意攻擊。那裏的結構過於舒適;
聽起來好像有很多重播攻擊的機會;
Blowfish使用什麼分組密碼模式？

我建議使用TLS/SSL - 它有很多更友善的眼神看着它的很多比更長的東西你建立自己永遠不會。

來源

2010-02-09 00:14:48 caf

感謝您對此的深思熟慮，特別是關於PRNG熵的部分。這是我特別關心的一部分，但不知道在你說出來之前如何在技術上提及它。永遠不知道SSL的真正含義，我確實創建了一個非常相似的系統，但是自己翻了一番，就像你說的那樣，它幾乎總是不那麼安全。展望未來，我將實施SSL加密，而不是我自己的滾動解決方案。感謝您的建議。 – 2010-02-09 20:36:16

從這一點上來說，當客戶端發送信息到服務器，這將是與明文sess_id &包括河豚加密的消息，使用相應的會話ID作爲密鑰來加密/解密。

如果您以明文形式發送會話標識，並將其用作加密密鑰，那麼安全性如何？

我看不出爲什麼你不能使用標準的SSL認證，並讓庫實現者擔心握手。

來源

2010-02-08 15:43:59 Draemon

我沒有將會話ID用作密鑰。我將它作爲索引發送給安全MySQL服務器上的表的索引，該服務器在首次使用硬編碼和非共享密鑰的河豚進行加密之後存儲blowfish祕密（客戶端的會話blowfish密鑰以加密方式存儲在數據庫中）。所以......它不是那麼可怕的設計。 - 我原來的文章沒有真正說清楚，對不起。 – 2010-02-08 15:47:31

好的，那很明顯。我仍然認爲SSL會更容易。 – Draemon 2010-02-08 16:04:48

你說得對，SSL會更容易，更安全。經過進一步調查（我不知道這正是SSL所做的（或多或少）），我已決定繼續使用SSL進行項目。謝謝你的建議。 – 2010-02-09 20:37:54

只需使用SSL或DTLS，IKEv2，HIP，EAP或一些合適的標準協議。不要試圖發明自己的加密協議，沒有人有足夠的專業知識來自己做這件事。你的協議中沒有足夠的熵，就我所見，所以你的結果鍵會很弱。

來源

2010-02-08 22:17:56

感謝您的回覆。我將爲這個項目使用全面的SSL和我自己的滾動解決方案。我只是不知道SSL是什麼/實現（企業架構明智）的細節足夠好以便從一開始就使用它。現在我知道我要這樣做的方式並不安全，我會堅持使用SSL。 – 2010-02-09 20:39:33

非對稱密鑰切換的對稱密鑰

回答

相關問題