AES CTR模式的互操作性？ [英] Interoperability of AES CTR mode?

问题描述

我使用AES128加密在CTR模式加密，实现为不同的客户端（Android / Java和iOS / ObjC）。加密数据包时使用的16字节IV形成如下：

I use AES128 crypto in CTR mode for encryption, implemented for different clients (Android/Java and iOS/ObjC). The 16 byte IV used when encrypting a packet is formated like this:

<11 byte nonce> | <4 byte packet counter> | 0

包发送的数据包计数器最后一个字节用作块计数器，因此具有少于256个块的分组总是获得唯一的计数器值。我的假设是CTR模式指定计数器应该为每个块增加1，使用最后8个字节作为计数器在一个大端方式，或者这至少是一个事实上的标准。这在Sun crypto实现中也是这样。

The packet counter (included in a sent packet) is increased by one for every packet sent. The last byte is used as block counter, so that packets with fewer than 256 blocks always get a unique counter value. I was under the assumption that the CTR mode specified that the counter should be increased by 1 for each block, using the 8 last bytes as counter in a big endian way, or that this at least was a de facto standard. This also seems to be the case in the Sun crypto implementation.

当对应的iOS实现（使用CommonCryptor，iOS 5.1）无法解码每个块时，我有点惊讶除了第一个解码分组时。看来CommonCryptor以某种其他方式定义计数器。 CommonCryptor可以以大端模式和小端模式创建，但是CommonCryptor代码中的一些模糊的注释表明这不是（或者至少没有被完全支持）：

I was a bit surprised when the corresponding iOS implementation (using CommonCryptor, iOS 5.1) failed to decode every block except the first when decoding a packet. It seems that CommonCryptor defines the counter in some other way. The CommonCryptor can be created in both big endian and little endian mode, but some vague comments in the CommonCryptor code indicates that this is not (or at least has not been) fully supported:

http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-60026/Source/API/CommonCryptor.c

/* corecrypto only implements CTR_BE.  No use of CTR_LE was found so we're marking
   this as unimplemented for now.  Also in Lion this was defined in reverse order.
   See <rdar://problem/10306112> */

通过逐块解码，每次设置上面指定的IV时，它工作得很好。

By decoding block by block, each time setting the IV as specified above, it works nicely.

我的问题：在一次解码多个块时，是否有一种正确的方式来实现CTR / IV模式，或者我希望它是互操作性问题当使用不同的加密库？是CommonCrypto在这方面的bug，还是只是一个实现CTR模式不同的问题？

My question: is there a "right" way of implementing the CTR/IV mode when decoding multiple blocks in a single go, or can I expect it to be interoperability problems when using different crypto libs? Is CommonCrypto bugged in this regard, or is it just a question of implementing the CTR mode differently?

推荐答案

（宽松地）在 NIST建议sp800-38a附录B < a>。注意NIST只指定如何使用CTR模式的安全性;它没有为计数器定义一个标准算法。

The definition of the counter is (loosely) specified in NIST recommendation sp800-38a Appendix B. Note that NIST only specifies how to use CTR mode with regards to security; it does not define one standard algorithm for the counter.

要直接回答你的问题，无论你做什么，你应该期望计数器每次增加一。根据NIST规范，计数器应当表示128位的大端整数。可能只有最低有效位（最右边的位）递增，但通常不会产生差异，除非您通过2 ^ 32 - 1或2 ^ 64 - 1值。

To answer your question directly, whatever you do you should expect the counter to be incremented by one each time. The counter should represent a 128 bit big endian integer according to the NIST specifications. It may be that only the least significant (rightmost) bits are incremented, but that will usually not make a difference unless you pass the 2^32 - 1 or 2^64 - 1 value.

为了兼容性，您可以决定使用第一个（最左边的）12个字节作为随机随机数，并将后者留空，然后让CTR的执行增量。在这种情况下，您只需在开始时使用一个96位/ 12字节的随机数，这种情况下不需要包计数器。

For the sake of compatibility you could decide to use the first (leftmost) 12 bytes as random nonce, and leave the latter ones to zero, then let the implementation of the CTR do the increments. In that case you simply use a 96 bit / 12 byte random at the start, in that case there is no need for a packet counter.

^ 32 * 16字节的明文，直到计数器使用所有可用位。如果计数器返回零，或者如果计数器中包含随机数本身，那么它是实现特定的，因此您可能想限制自己的消息为68,719,476,736 =〜68 GB（是的基数为10，Giga 表示 1,000,000,000）。

You are however limited to 2^32 * 16 bytes of plaintext until the counter uses up all the available bits. It is implementation specific if the counter returns to zero or if the nonce itself is included in the counter, so you may want to limit yourself to messages of 68,719,476,736 = ~68 GB (yes that's base 10, Giga means 1,000,000,000).

• 因为生日问题，您有2 ^ 48次机会（48 = 96/2）碰撞为每个消息，而不是每个块），所以你应该限制消息的量;


• 如果一些攻击者欺骗你进入解密2

• because of the birthday problem you've got a 2^48 chance (48 = 96 / 2) of creating a collision for the nonce (required for each message, not each block), so you should limit the amount of messages;
• if some attacker tricks you into decrypting 2^32 packets for the same nonce, you run out of counter.

如果这仍然不兼容（测试！），然后使用初始8字节作为随机数。不幸的是，由于生日问题，您需要限制邮件数量。

In case this is still incompatible (test!) then use the initial 8 bytes as nonce. Unfortunately that does mean that you need to limit the number of messages because of the birthday problem.

这篇关于AES CTR模式的互操作性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！