title: Interoperability of AES CTR mode?
body: <p>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:</p>
  
  <pre><code>&lt;11 byte nonce&gt; | &lt;4 byte packet counter&gt; | 0
  </code></pre>
  
  <p>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.</p>
  
  <p>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:</p>
  
  <pre><code>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 &lt;rdar://problem/10306112&gt; */
  </code></pre>
  
  <p>By decoding block by block, each time setting the IV as specified above, it works nicely.</p>
  
  <p>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?</p>