需要非常快速的一對一算法，可能需要加密

我需要非常非常快速的一對一算法。該算法不需要牢不可破。合理的強度已經足夠，但它必須閃電般快。我將用硬件來實現它。面積也是一個問題，所以它不應該使用太多的邏輯。需要非常快速的一對一算法，可能需要加密

它應該是一個函數f_N（x），它的輸入是一個N位數，其輸出是一個N位數。 N是一個常數，可能在20-70之間。該功能必須是一對一的。（即可逆的，這意味着解密是可能的解密速度是無關緊要的）。

我需要加密在3ns以下，這是約333M每秒輸入。例如，DES的速度大約爲每秒50Mbits。我需要每秒333M 輸入。

到目前爲止，我一直在使用約6輪的Feistel密碼。這似乎需要約3ns。

對此提出建議？

更多音符

出現了一些問題，所以我會解釋。我需要把密鑰放到哈希表中。標準方法是對輸入鍵進行散列處理，並將結果作爲索引放入表中。表中的每一行都必須存儲原始密鑰。 Information theory告訴我們表中的行實際上不需要與輸入鍵一樣寬，而是與輸入鍵一樣寬，在表的地址中的位數不會少於。例如：

輸入：X（N位）
散列：X％128（8個比特）
驗證：地板（X/128）（N-8位）

這將是愚蠢的CPU整數通常是相同的寬度，但我在硬件上做。

x％128是一個很容易破解的散列。事實上，如果輸入鍵只在前幾位有所不同，那麼您將在意外中破解散列。我想要一個在事故中不會被破壞的散列，甚至可能很難有意破壞。我也試過LFSR。 LFSR很快，但是兩個等長的LFSR會生成線性相關的哈希結果。（如果f（x）和g（x）爲兩個不同的多項式給出相同的散列值，則f（x + 1）和g（x + 1）容易相關）。位輸入和V位，H位輸出（V + H = N），在這裏很難找到兩個長度爲N的輸入，這樣兩個輸出將輸出相同的H.加密符合法案，因爲它使輸出與輸入長度相同並且很難反轉。除了加密以外的東西也可能工作，儘管看起來我想要的幾乎就是加密的定義。

對不起，沒有解釋所有這些預先。希望這可以澄清事情。

來源

2009-05-04 Eyal

對Andrew Hare的帖子的評論意味着你需要一個加密散列。這很重要，因爲R.A.的回答（TEA）不適合作爲散列--XBox安全性非常依賴於它。 – MSalters 2009-05-04 12:29:59

如果需要散列而不是加密算法，請*相應地編輯您的問題，因爲它們有很大的差異。但是你確實提到它需要是可逆的... – 2009-05-04 12:58:25

你沒有解釋你的6輪feistel密碼的問題。這聽起來很不錯。 – 2009-05-04 13:53:29

當你說「快」時，你只關心吞吐量，還是延遲本身最重要？

如果延遲不如吞吐量那麼重要，是否有任何理由不能使用已知安全的標準Feistel cipher，而不是進行全部輪次（例如Blowfish中的16）從組合邏輯輸出，在每一輪之間插入一個寄存器，以便管理加密算法？它本質上需要相同數量的硬件（爲寄存器添加一些觸發器）作爲已知的安全加密算法，但傳播延遲僅爲Feistel網絡的一輪傳播延遲人字拖鞋。

來源

2009-05-04 13:23:38

我想知道如果你不關心加密的強度，那麼也許你根本不需要進行加密。 大多數加密算法的重要組成部分是它的實力。如果加密功能很弱，那麼你首先通過加密就沒有什麼好處。

來源

2009-05-04 11:49:36

這是真的，我不是真正的加密。我需要的是一個從N位映射到N位的函數。該函數必須是一對一的，並且很難猜測兩個輸入會產生只有一個或兩個比特的輸出，類似於散列函數的限制。 – Eyal 2009-05-04 11:59:15

您的陳述其實並非如此。信息被充分加密，如果它被破壞時發生的全部損失沒有超過破壞它的成本，現在和將來。有了這麼多的每秒輸入，在任何情況下，解密整個流的成本都將非常高。 – MSalters 2009-05-04 12:27:10

我會建議我的老朋友，在Tiny Encryption Algorithm

這是既快速又上足跡，這也可能有在硬件實施時要考慮極低。

來源

2009-05-04 11:56:21 sharkin

使用64位「鍵」值和異或字節每個字節有什麼問題？您可以根據需要多次遍歷密鑰，以在第一個64之後輸入任何明文位。012位用戶密碼可以是8位密碼或8位密碼。

由於密鑰的位數與消息的位數差不多，所以實際上它會相當強大且速度非常快。

來源

2009-05-04 12:16:52

這裏有一些基準測試的一些算法：http://gd.tuwien.ac.at/privacy/crypto/libs/cryptlib/benchmarks.html

注意，這些基準測試是測試實現的算法，所以它可能不是你所期待的。

來源

2009-05-04 12:22:00 soulmerge

以下內容不符合您對一對一功能的要求，但如果速度至關重要，也許可能有用。（如果它不起作用，那麼我會建議一個分而治之的路線：你正在使用硬件，所以理論上你應該能夠並行加密和解密，除非一個輸入的加密依賴於先前輸入的加密。）

剛想最快硬件算法我稱之爲「改寫（munging）」，是在概念對待你輸入的比特流，並以加密安全和可重構位發生器的比特流輸出XOR他們 - 可重構如果你想解密它。一個簡單且閃電般的例子，但其本身並不安全，是一個linear feedback shift register（LFSR）。選擇很長時間（2 - 1或2 - 1或類似的東西）。維基百科頁面建議進行修改以增強安全性。您也可以偶爾嘗試（例如，每M個位一次，其中M = 4096,16384,65536，無論如何）將LFSR的狀態與較慢但更安全的位流的輸出進行異或（流密碼或分組密碼，預定的一組輸入，例如增量序列，或者LFSR狀態的延遲快照） - 儘管這屬於你自己的發明密碼技術，這個想法是衆所周知的密碼技術已經大用於測試是否存在漏洞的能量投入量。

來源

2009-05-04 13:15:03

如果你是在硬件上做這個，爲什麼你不使用DSP上的標準塊密碼？

How Well Are High-End DSPs Suited for the AES Algorithms?

來源

2009-05-08 17:52:46

需要非常快速的一對一算法，可能需要加密

回答

相關問題