AES/CFB8 8的高效解密

Question

目前，我使用此函数解密以CFB8模式加密的AES数据流：https://github.com/Lazersmoke/civskell/blob/ebf4d761362ee42935faeeac0fe447abe96db0b5/src/Civskell/Tech/Encrypt.hs#L167-L175。

cfb8Decrypt :: AES128 -> BS.ByteString -> BS.ByteString -> (BS.ByteString,BS.ByteString)
cfb8Decrypt c i = BS.foldl magic (BS.empty,i)
  where
    magic (ds,iv) d = (ds `BS.snoc` pt,ivFinal)
      where
        pt = BS.head (ecbEncrypt c iv) `xor` d
        -- snoc on cipher always
        ivFinal = BS.tail iv `BS.snoc` d

如果您不理解Haskell，下面简要介绍一下我认为这段代码是如何工作的：(我没有编写它)

• 给出一个IV和一个加密字节列表
• 每个加密字节：
  • 在欧洲央行模式下加密IV。
  • 获取加密的IV的第一个字节，并使用加密的字节对其进行xor。这是下一个明文字节。
  • 从IV中删除第一个字节
  • 将加密的字节追加到IV中
  • 下一个字符将使用这个新的IV解密。

​

不是说欧洲央行模式的加密是由密码库处理的。我找不到一个支持CFB8的库。

现在，这是可行的。然而，随着我需要解密的数据量，它限制了我的一个CPU核心，80%的时间只是用于解密。

传入的数据甚至没有那么多，所以这是不可接受的。不幸的是，我对密码学的知识相当有限，而CFB8上的资源似乎相当稀少。CFB8似乎是一种不常见的操作模式，也表现为缺乏库支持。

那么，我的问题是:我将如何优化这一点？

传入的数据来自TCP流，但信息被分组。根据大小，每个包调用cfb8Decrypt函数2-5次。这是必要的，因为数据包的长度是在开始发送的，但是这个大小信息的长度是可变的。在使用1-4解密对长度进行解密后，整个数据包将立即解密。我曾想过要减少这种情况，但我不确定它是否会对速度产生任何影响。

编辑:分析结果：http://svgur.com/i/40b.svg

Answer 1

CFB8是为了在噪声信道上具有良好的误差传播特性而创建的。众所周知，它并不快；它实际上是速度的16倍，因为它需要对每个字节进行块加密。目前，它并不是很热门，因为我们倾向于使用CRC作为数据层，而MAC用于加密级别上的完整性，以防止任意攻击。

你怎么能加快速度？你唯一能做的就是使用一个快速的库。您目前使用的库似乎支持AES-NI，所以请确保在CPU和BIOS上启用了它。

然而，如果你不得不把它称为一个又一个块的话，它很可能不会加速太多。您确实希望使用一个本机调用，该调用接收整个数据包并对其进行解密。AES-NI在Atom实现TLS上是最慢的，但在服务器芯片上，AES-NI常常远远超过1 GiB/s的限制。当AES-NI不可用时，装配或优化的C应该是速度的6/7倍。

像Haskell这样的函数式编程语言并不是真正为快速I/O或快速位操作创建的。因此，您可以打赌，它将比例如Java或C#慢得多，而且它们已经比本机代码慢得多，更不用说组装代码或专用指令了。

现在的内存相当快，但是CPU的速度要快得多。因此，应该避免错误的内存分配和复制(同样，在功能齐全的语言上做起来不那么容易，更有理由在本机代码中尽可能多地执行)。但是，请确保没有缓冲区溢出问题，否则在不安全的应用程序中会有快速的AES/CFB。