Not to detract from the important discussion of how best to use AES CTR mode, but I have a more basic question...
I can certainly understand why the discussion of CTR mode is considered to be boring. I assume that anyone can easily verify that testing trillions of different 128-bit counter values, even in incremental sequence, produces radically different xor masks, given a "reasonable" IV. But what's the probability of 2 xor masks colliding? Is this just assumed to be random, i.e. compatible with a birthday attack? Has anyone done anything like a limit median iteration count before repetition (LMICBR) test or scintillating entropy test? (These are described in detail on my blogs.) The former test, which could actually be performed in useful fashion on a 128-bit space using existing computer power, would likely throw up warning signs if the cycle were too short. The latter test would potentially shrink the upper bound complexity estimate for differential (i.e. interblock) cryptanalysis. So if, let's say, 2 in every 100 xor masks collide, then I need only store 100 encrypted blocks in order to have a good chance of finding of a matching pair (or n-tuple) of xor masks, thereby facilitating statistical cracking methods. Obviously 100 is too small. So what is the actual number, for a given counter width? Personally, I'd prefer to rely on the predictable limit cycles of Karacell 3 (but then, I'm biased). But I'm quite open to a demonstration or whitepaper showing that CTR limit cycles are also predictable and usefully long. Or maybe I've just misunderstood how CTR works. Anyone?
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
