我需要一个非常非常快的一对一算法。算法不需要是不可打破的。合理的强壮是足够的,但它必须是闪电般的快。我将在硬件上实现它。领域也是一个关注,所以它不应该使用太多的逻辑。
它应该是一个函数f_N(x),它的输入是N位数,输出是N位数。N是一个常数,可能在20-70之间.函数必须是一对一的。(指解密是可能的).解密速度无关。)
我需要在3ns以下加密,大约是每秒33300万个输入。例如,DES每秒处理大约50 about。我需要3.33亿每秒输入。
到目前为止,我已经使用了6发左右的Feistel密码。这似乎需要大约3N。
有什么建议吗?
更多笔记
有一些问题,我会解释的。我需要把钥匙放进哈希表。标准方法是对输入键进行散列,并将结果作为索引使用到表中。表中的每一行必须存储原始键。信息论告诉我们,表的行实际上不需要像输入键那样宽,而是像输入键一样宽,减去表地址中的位数减去。例如:
在CPU上,如果整数通常是相同宽度的,那就太傻了,但我是在硬件上这样做的。
x%128是一个很容易中断的散列。实际上,如果输入键仅在前几位中不同,那么您将在意外情况下破坏哈希。我想要一个不会因意外而被打破,甚至很难故意打破的哈希。我还试过一个LFSR。LFSR是快速的,但是两个等长的LFSR产生线性相关的散列结果。(如果f(x)和g(x)对两个不同的多项式给出相同的散列,则f(x+1)和g(x+1)易于关联。
因此,我需要一个具有N位输入和V位,H位输出(V+H=N)的函数,其中很难找到两个长度为N的输入,这样两种输入都会输出相同的H。加密符合法案,因为它使输出与输入保持相同的长度,而且很难逆转。除了加密之外,其他东西也可能有效,尽管我想要的似乎是加密的定义。
很抱歉没有提前解释这一切。希望这能澄清问题。
发布于 2009-05-04 13:23:38
当你说“快”时,你只关心吞吐量,还是延迟本身是最重要的?
如果延迟不像吞吐量那么重要,那么您为什么不能使用已知安全的标准Feistel密码,而不是使用组合逻辑输出的全部轮数(例如16轮),那么在每一轮之间添加一个寄存器,这样您就可以编写加密算法了吗?它本质上需要与已知的安全加密算法相同数量的硬件(为寄存器添加一些触发器),但传播延迟仅为Feistel网络的一轮+触发器的传播延迟。
发布于 2009-05-04 11:49:36
我想知道如果你不关心加密的强度,那么也许你根本不需要加密。加密算法中最重要的部分是加密算法的强度。如果加密是弱的,那么从一开始加密就没有任何好处。
发布于 2009-05-04 12:22:00
下面是一些带有一些算法的基准测试:http://gd.tuwien.ac.at/privacy/crypto/libs/cryptlib/benchmarks.html
请注意,这些基准测试正在测试算法的implementations,因此可能不是您要寻找的。
https://stackoverflow.com/questions/819765
复制相似问题