Open Radar

 
Summary:
The CCCryptorReset() function is documented to allow changing the IV of a cipher without changing its key. When applied to a CTR-mode cryptor (which takes its initial counter state from the IV parameter of CCCryptorCreateWithMode etc.), it has no effect.

Steps to Reproduce:
Create a CTR-mode cryptor. Encrypt a few blocks. Use CCCryptorReset() to attempt to jump to another point in the keystream. Encrypt a few more.

The attached program does this; its output is:

Initial CTR output values:
  1:  3247184B3C4F69A44DBCD22887BBB418
  2:  9BB22CE7D9F372C1EE2B28722B25F206
  3:  650D887C3936533A1B8D4E1EA39D2B5C

After resetting CTR to initial state:
  1:  3DE91827C10E9A4F5240647EE5221F20
  2:  AAC9E6CCC0074AC0873B9BA85D908BD0
  3:  DDA867C4CEF2B1F1B8A9FF49CA208B61

Implementing CTR using ECB for reference:
  1:  3247184B3C4F69A44DBCD22887BBB418
  2:  9BB22CE7D9F372C1EE2B28722B25F206
  3:  650D887C3936533A1B8D4E1EA39D2B5C
  4:  3DE91827C10E9A4F5240647EE5221F20
  5:  AAC9E6CCC0074AC0873B9BA85D908BD0
  6:  DDA867C4CEF2B1F1B8A9FF49CA208B61


Expected Results:
The output data under "After resetting CTR" should be the same as "Initial CTR output".

Actual Results:
The data differs. In fact, you can tell from the kCCOptionECBMode-based CTR implementation output that the "After resetting..." output is simply the continuation of the cryptor's state as if CCCryptorReset() had never been called at all.

Version:
Xcode: 6.0 (6A280n)

OSX:
10.9.4/13E28
10.10/14A343f

(same behavior on both versions of OSX)

Notes:
This can be worked around by creating a new cryptor, but that's an expensive operation (key schedule setup).

This can be worked around by only using CommonCrypto in ECB mode and doing the CTR stuff myself, but that's kind of ridiculous.


Configuration:


Attachments: