需要一个非常快速的一对一算法,可能是加密

时间:2009-05-04 11:46:50

标签: encryption hardware cryptography

我需要一种非常非常快速的一对一算法。该算法不需要是牢不可破的。合理的强度足够但它必须闪电般快速。我将在硬件中实现它。区域也是一个问题,因此它不应该使用过多的逻辑。

它应该是一个函数f_N(x),其输入是一个N位数,其输出是一个N位数。 N是常数,可能在20-70之间。该功能必须是一对一的。 (即可逆,意味着解密是可能的。解密速度无关紧要。)

我需要在3ns以下加密,每秒大约333M输入。例如,DES每秒大约需要50Mbits。我每秒需要333M 输入

到目前为止,我一直在使用一个大约6轮的Feistel密码。这似乎需要大约3ns。

建议?

更多备注

有一些问题,所以我会解释。我需要将密钥放入哈希表。标准方法是对输入键进行哈希处理,并将结果用作表的索引。表中的每一行都必须存储原始密钥。 Information theory告诉我们,表的行实际上并不需要与输入键一样宽,而是与输入键 less 一样宽,地址中的位数的表。例如:

  • 输入:x(N位)
  • hash:x%128(8位)
  • 验证者:floor(x / 128)(N-8位)

对于整数宽度通常相同的CPU而言,这将是愚蠢的,但我是在硬件中进行的。

x%128是一个易于破解的哈希。实际上,如果输入键仅在前几位中有所不同,那么您将在意外时打破哈希。我想要一个不会在事故中被打破的哈希,甚至可能难以故意破坏。我也试过LFSR。 LFSR很快但两个相等长度的LFSR生成线性相关的哈希结果。 (如果f(x)和g(x)给出两个不同多项式的相同散列,则f(x + 1)和g(x + 1)很容易相关。)

所以,我需要一个具有N位输入和V位,H位输出(V + H = N)的函数,其中很难找到两个长度为N的输入,这样两者都将输出相同的H.加密符合要求,因为它使输出与输入的长度相同,并且很难反转。加密以外的东西也可能有用,虽然看起来我想要的几乎就是加密的定义。

很抱歉没有解释所有这些问题。希望这能澄清事情。

7 个答案:

答案 0 :(得分:5)

我想知道你是否不关心加密的强度,那么也许你根本不需要加密。加密算法的重要部分是它的强度。如果加密很弱,那么首先加密就没有任何好处。

答案 1 :(得分:2)

以下是一些使用某些算法的基准测试:http://gd.tuwien.ac.at/privacy/crypto/libs/cryptlib/benchmarks.html

请注意,这些基准测试正在测试算法的实现,因此它可能不是您要查找的内容。

答案 2 :(得分:2)

当你说“快速”时,你只关心吞吐量,还是延迟本身是最重要的?

如果延迟不如吞吐量那么重要,那么您是否有任何理由不能使用已知安全的标准Feistel cipher,而不是拥有完整数量的轮次(例如16在Blowfish中)从组合逻辑输出,在每一轮之间粘贴一个寄存器,以便管道加密算法?它本质上需要相同数量的硬件(为寄存器增加一些触发器)作为已知的安全加密算法,但传播延迟只能是Feistel网络的一轮传播延迟+人字拖鞋。

答案 3 :(得分:1)

我会推荐我的老朋友Tiny Encryption Algorithm

它的占用空间非常快且非常低,在硬件实现时您可能还需要考虑这一点。

答案 4 :(得分:0)

使用64位“密钥”值并对每个字节进行xor-ing有什么问题?您可以根据需要多次循环键,以便在第一个64之后对任何明文位进行xor。

64位密钥可以是8个字符的密码,也可以是8个字节的密码短语。

由于密钥的位数几乎与消息一样多,因此它实际上会非常强大且非常快。

答案 5 :(得分:0)

以下内容不能满足您对一对一功能的要求,但如果速度至关重要,它可能会有用。 (如果它不起作用,那么我建议划分和征服路线:你在硬件上工作,所以理论上你应该能够并行加密和解密,除非一个输入的加密依赖于先前输入的加密。 )

对于我称之为“munging”的最快硬件算法,就是将您的输入在概念上视为比特流,并将它们与加密安全和可重构的比特生成器的比特流输出进行异或运算 - - 如果你想解密,可以重建。一个简单且闪电般的例子,但本身并不安全,是一个linear feedback shift register(LFSR)。选择一个长期(2 128 - 1或2 256 - 1或类似的东西)。维基百科页面建议修改以增强安全性。您也可以偶尔尝试(例如,每M位一次,其中M = 4096,16384,65536,无论如何)将LFSR的状态与较慢但更安全的比特流的输出进行异或(流密码或分组密码加密预定的一组输入,例如递增序列,或LFSR状态的延迟快照) - 虽然这属于不发明你自己的加密技术,但这个想法是众所周知的加密技术已经很大投入大量精力测试是否存在漏洞。

答案 6 :(得分:0)

如果您在硬件中执行此操作,为什么不在DSP上使用标准分组密码?

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