用于DRM的密码速度比美学256-CBC快

Question

我必须为一个学校项目开发一个使用“秘密”本地编码程序的程序。为此，我必须在飞行中破译密码才能使用它。该项目推荐在CBC模式下使用AES 256，但是为了更好的性能，欢迎任何建议。

所以我有两个问题：

1. 我自己实现了AES (我知道这是不推荐的，但在项目中是强制性的)，我希望将它与最快的软件实现进行比较，知道在哪里可以找到它吗？
2. 我正在寻找更快的密码，但或多或少比AES更“安全”来建议和实现。到目前为止，我发现了不少: CLEFIA、Threefish、Salsa20和LWC:PRESENT、LEA、ASCON(AEAD?)我知道LWC上的安全性远低于标准加密(尽管SC和LWC之间的差别并不明显)，但它们似乎没有被破坏。它们应该被用于我的目的吗？如果没有其他建议的话？

谢谢

Answer 1

如果您正在编写您自己的AES实现，并且可以使用AES-NI指令集，那么您将得到一个在数学上安全且快速的密码。非常快..。硬件中的AES通常比存储设备快。

您还可能陷入将数学安全密码与大密钥大小等同为该密码的安全实现的陷阱。如果不使用CPU指令或一种特殊的代码(如掩蔽)，这将使您的实现变得缓慢和复杂，那么就很难实现一个安全的AES实现。如果分级的一部分是你的DRM方案有多安全，而且尽管你使用了一个安全的分组密码，它显然是可以破解的，这对你的成绩可能不是个好兆头。

一个既快速又安全的密码，即使没有硬件加速指令，也将是ChaCha8。它是一种计数器模式流密码，可以比非加速的AES快得多，同时也可以更安全地实现。如果你能使用矢量指令的话，它甚至可以和带有硬件加速的AES一样快。

如果您正在寻找完整性保护，它通常是配对的Poly1305 MAC，虽然您也可以使用HMAC以及可能是较不复杂的实现，但一般较慢，只要你有选择产生更多的关键材料。

最后，请考虑如果使用带密钥的分组密码，这些密钥是如何存储、管理和创建的。许多DRM方案由于密钥创建或管理不善而被挫败。如果只有1000个唯一的输入键，使用128位密码将不会提供安全性。

Answer 2

试试OpenSSL。它有汇编语言例程，利用CPU的特定指令来加速AES。构建OpenSSL时，必须启用程序集例程。

当Oracle添加类似于对Java的支持时，它们的性能提高了几个数量级。这是Java，而不是C，所以这并不奇怪，因为OpenSSL的增长非常大，而且您不会看到这种增长。有关详细信息，请参阅这。