[tcas]

It's explained pretty well in the article. Basically with CTR using the block # as the nonce you break the security assumptions of a nonce (use only once). If the cryptofunc is static, and you are editing a document in place, an attacker can see exactly which bytes changed and do other statistical attacks.

Think about a file that you preallocate with NULLs. If you get an image of the disk before you write to the file and then an image once you write to the file, you can simply XOR the before and after to get the ciphertext.

e.g.

  using block 100
  cipherblock_before = cryptofunc(100) ^ 0x00 = cryptofunc(100)
  cipherblock_after = cryptofunc(100) ^ data
  cipherblock_after ^ cipherblock_before = data

[midas007]

Yes, it's a known weakness. You have to rekey every X blocks.

[tptacek]

No, rekeying does not solve that problem, not to mention which you've just handwaved a hard problem (varying the key over different sectors). That's doable (though it again doesn't fix the problem with your proposal), but the resulting mode isn't CTR.

[midas007]

Yes it does, and it's still CTR.

Further, every solution is going to have other machinery solving specific concerns.

You don't call XTS something else because you've used scrypt or PBKDF2 as the PBKDF.

Work is work.

[tptacek]

This is a sequence of non-sequiturs, none of which respond to my comment. I'll make it easier for you:

Propose a scheme whereby you use AES-CTR to encrypt a 100 megabyte disk of 512-byte sectors, whereby the scheme "rekeys" every "few sectors". Be specific.

[midas007]

Don't need your "help," don't care.

"It's unreasonable to debate with an unreasonable person."

Bye.