AES-CTR安全性如果S-盒替代被省略？

Question

我理解为什么通常需要S盒，特别是当使用ECB模式时(因为使用相同的密钥对其他块进行加密)，但我不知道在这种情况下如果省略s-boxes替换步骤，它是否仍然相对安全。

• 使用AES-CTR模式确保具有相同块的相同密钥将加密到不同的密文
• 如果我们选择一个完全随机密钥

我是这样问的，因为这看起来就像我们加密的方式类似于一次加密(并不完全)，因为加密的结果(这将得到x与明文)是随机的。我知道使用S盒会增加安全性，但是这种方式对非绝密文档来说很好，所以我们可以为类似的嵌入式设备获得一些额外的性能，而不需要牺牲太多的安全性，也可以使用什么样的攻击。

Answer 1

Sbox是AES或类似分组密码安全的必要条件，但可能不是足够了。我们可以在较高级别上进行列出所有AES操作，如

• SubBytes -根据查找表将每个字节替换为另一个字节的非线性替换步骤。
• ShiftRows --一个转位步骤，其中状态的最后三行被周期性地移动--一定数量的步骤。
• MixColumns -一种线性混合操作，操作在状态的列上，将每列中的四个字节组合在一起。
• AddRoundKey

想知道在这种情况下，如果省略S盒替换步骤，它是否仍然是相对安全的？

如果省略了SubBytes，那么新的AES密码将是一个完全线性的密码。对于分组密码来说，这是完全失败的。当攻击者在简单的攻击中得到一个已知的明文时，他们将为任何AES建立128个线性方程组。如果方程没有线性依赖关系，那么他们可以用一个已知的明文对来求解AES-128。

您的设计没有KPA安全性，在现代密码学中，我们至少需要CPA安全性。

使用AES-CTR模式确保具有相同块的相同密钥将加密到不同的密文。

我有两个理解。

1. 每个块都使用一个新的密钥。这是没用的。
   1. 一种是使用这么多密钥来加密消息。
   2. 而不是这样，使用带有其他问题的密钥的OTP。
   3. 您需要一次又一次地运行密钥计划。

2. 使用一个键
   1. 人民军的攻击可以打破这一局面。

这样看来，我们的加密方式类似于一次加密(并不完全)，因为加密的结果(这将得到明文的x)将是随机的。

不完全是随机的，线性依赖于键。

相反，在现代密码学中，我们把PRF或PRP转换成类似CTR模式的流密码。PFR可以工作，因为CTR模式不需要PRF的反向。这样我们就可以在很长一段时间内使用一个密钥和一个密钥调度。AES-CTR或ChaCha是众多例子中的一个.AES被认为是一个PRP，但没有被证明。和。请记住，对于CTR模式，不应该再次使用密钥-IV对。

对于文件加密，最好使用AES-GCM或ChaCha20-Poly1305，这也提供了完整性和身份验证。AES-GCM更快，因为硬件支持，如英特尔的AES-NI.在我的机器上对AES-128 NI的打击

openssl speed -elapsed -evp aes-128-ctr
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     556160.77k  1822893.03k  3765397.08k  5115820.71k  5694253.74k  5739358.89k

如果有对ChaCha和Poly1305的硬件支持，它可以击败AES。