自修改哈希加密算法

我正在尋找一種算法來改變它的每個時期的密鑰，仍然可以破譯。
基本上我正在尋找一種方法來維護移動客戶端和固定服務器之間的安全鏈接，即使您截獲哈希或者甚至是身份驗證憑證本身，他們也會在每個時期雙方發生更改。
它會向任何人敲響鐘聲嗎？
有沒有更好的方法來確保即使您將以某種方式攔截身份驗證憑據，它也只會對來自特定用戶的某個請求有效？自修改哈希加密算法

來源

2010-02-25 the_drow

認證cardinals？當然你的意思是憑據？ – Seth

固定...誦讀困難吮吸：（ –

這聽起來像你聽過一些太多的技術犯人，只需使用SSL - 它已經解決了你可能遇到的所有問題 –

我推薦使用SSL，而不是自己實施一些加密算法（如果您試圖保護的數據足夠重要，它會被破壞！）。 SSL已經過很好的測試。使用SSL，您可以使用證書而不是登錄名/密碼。 SSL防止重放和中間人攻擊（它在開始時使用握手來確保每個連接都使用新的會話密鑰，並且雙方都聲稱自己是誰）。

想到另一個有趣的事情是RSA的SecurID。它提供了一個每60秒更換一次的硬件密鑰：http://www.rsa.com/node.aspx?id=1156

來源

2010-02-25 21:25:57 stmax

我想說RSA的SecurID正是我正在尋找的，但是你是什麼意思的「硬件密鑰？」 –

如果你按照上面的鏈接有一個這樣的硬件密鑰圖片（顯示當前密鑰的設備），我剛剛看到他們也提供軟件解決方案（用於個人電腦，手機......），但我喜歡這些硬件密鑰，因爲它們不能被黑客竊取。 – stmax

這當然是可能的 - 例如，第二次世界大戰期間的日本紫色密碼就是這樣做的。雖然這樣的密碼當然可能很難，但它也可能被破壞（紫色）。

原因很簡單：您的發送者和接收者必須生成新的密鑰，以便接收者能夠同步解密消息。這基本上意味着你需要安全的隨機數生成器來生成新的密鑰。雖然這可能很難打破（有足夠長的時間等等），但它仍然是一種非常普通的加密技術，並且依賴於擁有安全的隨機數生成器。但是，一旦你擁有了這個功能，你通常不會更直接地使用發生器的輸出（例如，作爲Vernam密碼的關鍵）。

來源

2010-02-25 21:07:01

我建議使用SSL。它被設計爲對中間人攻擊有合理的抵抗力，這是我認爲是你的擔心。

或者可能Kerberos。

不要自己編碼加密算法。

來源

2010-02-25 21:18:41 Brian

+1最後一行，最重要的（也是最常破的）密碼學原理 –

我猜你在說什麼是找到某種方式來定期更改算法中使用的加密密鑰，以便即使發現密鑰，用這個密鑰加密的數據可能被解碼？如果我們避免擔心啓動過程，那麼做到這一點的一種方法就是將部分（但不是全部）後續密鑰編碼到用一個密鑰加密的數據集中，並且當您切換密鑰時，加密一個不同的密鑰使用新密鑰的後續密鑰的一部分。例如，假設您的密鑰有8個元素寬（元素可能是一個字節或一個32位字或其他），並且我們將標記用於加密任何給定數據塊的密鑰作爲Kn，其中'n'是用該密鑰加密的數據塊。我們將索引第一個元素的Kn [0]，第八個元素的Kn [7]。我們也會調用這個數據塊Dn。然後，明文Dn將包括Kn + 1 [0]，Kn + 2 [1]，Kn + 3 [2]，...，Kn + 8 [7]。如果您能夠解密Dn-7 .. Dn，那麼您將完全重構Kn + 1，以便您可以解密下一個數據塊，依此類推。您需要依次獲取幾個塊的明文，然後才能可靠地解密其餘數據，但是獲取任何給定塊的明文將會使其餘部分的密鑰更容易受到攻擊。

初始設置是一個更難的問題。 SSL將是一種分配K0，K1 [1..7]，K2 [2..7]，...，K7 [7]的好方法。

我不是一個專業的密碼學家，所以我不完全確定這是多麼安全。此算法按原樣提供給您，不提供任何形式的保證。

來源

2010-02-25 21:35:17

自修改哈希加密算法

回答

相關問題