On DJB's blog he writes:
I was one of about 40 people sitting in a meeting where the speaker, NSA's Louis Wingers (one of the Simon and Speck authors), falsely claimed that counter mode is safe for 64-bit blocks, since counter mode doesn't have block collisions. NSA's continuing promotion of these dangerous ciphers includes perfect sentences to quote in the introductions of "provable security" papers studying small block sizes.
I can think of the following problems with 64 bit CTR mode (either used with HMAC or without the need for message authentication)
- The keystream can be distinguished from random if the length is close to (or greater than) $2^{32}$ blocks. No two blocks will have equal values assuming no counter overflow. The birthday effect means repeat block values are expected after around this many blocks.
- There is a potential plaintext information leak. For ciphertext $C$ and plaintext $P$ (for any length), only if $P_i \neq P_j$ may $C_i = C_j$ where $i \neq j$. This is true for CTR mode with any block size but is more of a problem for 64 bit blocks than for 128 bit blocks because the birthday limit for 64 bit blocks is smaller.
- Random IV collisions are too common because the maximum length of the IV is less than 64 bits.
Are there other problems for CTR mode associated with 64 bit block sizes? (Perhaps associated with different message authentication algorithms.) If not, then what is Bernstein referring to? The problems I identified seem like they would be minor if keys can be regenerated to avoid encryption of too many blocks with the same key.
I hope my list is not exhaustive just so I don't need to post an answer to my own question. Besides mathematical problems I suspect there are a lot of human problems. Those alone I think are serious enough to justify completely discouraging 64 bit block sizes. Plus I believe the IV problem is especially serious.