| 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. |
Indeed, even if blockcipher=AES256, the attacker can still break CTR by merely guessing key in 2²⁵⁶ operations. (Likely only one such value of key will yield meaningful plaintext throughout the entire multi-block message.) That is contrary to the information-theoretic security property of OTP, where the attacker can't tell whether they've correctly guessed the key.
More to tptacek's point, if you're using the block offset as i, then if you write the same block 30 times, you used the same value blockcipher(key, nonce . i) each time. That isn't a one-time use of that part of the pad, it's a 30-time use of that part of the pad. It's extremely possible that an attacker who has observed all 30 ciphertexts can actually decrypt many of them in combination. In Boneh's Coursera class, we did it successfully with like 4 or 5 ciphertexts, and I've seen a paper that describes doing it automatically for the majority of the text with only two ciphertexts, assuming the plaintext is English written in ASCII.