[midas007]

? What's wrong with CTR? CTR is basically an OTP. Being OTP, encryption and decryption are basically the same construction (thank you XOR).

    cipherblockdata = blockcipher(key, nonce . block #) ^ plainblockdata
    plainblockdata = blockcipher(key, nonce . block #) ^ cipherblockdata

If MAC is needed, that can happen after encrypting, before decrypting. (Needed if bytes traverse network, but maybe not for local disk or file encryption unless.)

Edit fixed my maths:

[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]

CTR is not a one-time pad. Read the article: it discusses using CTR for disk encryption.

[midas007]

Pretty hilariously wrong, and you know it.

Supposed OTP constructions are defined as

e(i) == E(...) ^ m(i)

m(i) == D(...) ^ e(i)

where E(...) = D(...)

and where ... doesnt contain any of the following

e(j) for any j

m(k) for any k

j and k in same domain as i

Then, take a look at CTR...

CTR is E(i) = blockcipher(key, nonce . i) and D(i) = E(i)

e(i) == blockcipher(key, nonce . i) ^ m(i)

m(i) == blockcipher(key, nonce . i) ^ e(i)

(i == counter, since it's the same in this example where counter and blocks start at the same number)

Therefore CTR is an OTP.

[lvh]

Uh, yeah, except not a cryptographic hash function, first of all :-)

Secondly, CTR has serious issues too. It is trivial to bit-fiddle. The naive implementation you're suggesting leaks the keystream in one CCA query.

Just because CTR in and of itself is easy to get right doesn't mean that any system composed using CTR is easy to get right.

[tptacek]

The trivial malleability of CTR is apparently why NIST rejected it, but it's important to remember that most unauthenticated block cipher modes are malleable, including XTS.

[midas007]

Fixed.

That's beyond the scope of which mode, but it's important. However the less code one has, the fewer places there are for things to hide.