我read认为AES 128 CTR模式应该适用于16字节（128位）的块，就像CBC模式一样。
实际上，如果我尝试使用openssl来编码18个字节的纯文本：
max@jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nopad -nosalt -aes-128-cbc -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
bad decrypt
140670739715200:error:0607F08A:digital envelope routines:EVP_EncryptFinal_ex:data not multiple of block length:../crypto/evp/evp_enc.c:425:
00000000 14 f5 fe 74 69 66 f2 92 65 1c 22 88 bb ff 46 09 |...tif..e."...F.|
00000010
max@jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nosalt -aes-128-cbc -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 14 f5 fe 74 69 66 f2 92 65 1c 22 88 bb ff 46 09 |...tif..e."...F.|
00000010 c2 ae b2 99 18 cd 6e ee 55 92 77 d9 e8 f3 1f bf |......n.U.w.....|
00000020
密文为16或32个字节，具体取决于-nopad参数的存在。
但是如果我尝试点击率：
max@jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nopad -nosalt -aes-128-ctr -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 56 d8 79 e7 db bf 1a 0c b0 75 9b 3b a9 50 4e 48 |V.y......u.;.PNH|
00000010 3f 8a |?.|
00000012
max@jarvis:~$ printf 0123456789abcdefgh | openssl enc -e -nosalt -aes-128-ctr -K 00000000000000000000000000000000 -iv 00000000000000000000000000000000 | hd
00000000 56 d8 79 e7 db bf 1a 0c b0 75 9b 3b a9 50 4e 48 |V.y......u.;.PNH|
00000010 3f 8a |?.|
00000012
在每种情况下，密文均为18个字节，就像纯文本一样。
我不知道为什么
答案 0 :(得分：4)
CTR模式使分组密码（如AES）充当流密码。预期的结果是预期的-输入数据的大小将等于输出数据的大小。
CBC逐块操作，这是强制执行填充方案的原因。 CTR将计数器值的块传递给AES，但仍然遵循块大小，但随后将输出块与明文进行异或。
在上述情况下，两个完整的128位块将通过AES传递以生成密钥流，但是仅使用该密钥流的128 + 16位（18字节）并将其与您的纯文本进行XOR运算，从而产生一个等长的密文。
答案 1 :(得分：0)
AES 128 CTR与AES 128 CBC非常不同，您链接到的维基百科页面非常清楚。请注意，明文是如何在CBC模式下注入加密块的，但绝不会在CTR模式下通过加密块。
CTR加密是通过获取一个随机数，一个块计数器（CTR！）和密钥，并对它们进行加密以制成很难猜测的伪随机数据块（称为密钥流）来完成的。密钥流与明文进行异或运算，以获得密文。 XOR是按字节进行的，因此您可以截断密钥流以匹配明文的长度。请注意，明文永远不会接受AES块密码加密。分组密码用作生成伪随机密钥流的单向函数。 CTR不仅可以用于AES加密模块，还可以用于各种密钥流来源。
对于第一个块，开始CBC的方法是：将明文与随机初始化矢量（IV）进行异或，然后将其实际通过AES块密码加密。前一个块的密文用作后继块的新IV，即永远不会重用IV。