What? No. Don't do that.
cipherblockdata = blockcipher(key, nonce . block #) ^ plainblockdata
plainblockdata = blockcipher(key, nonce . block #) ^ cipherblockdata
Edit fixed my maths:
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.
Hair-splitting, really. Actual OTP is an imaginary construction that requires an endless supply of truly random bits that have to be securely stored or somehow recreated during decryption. It shifts the hard part to that fn, and just XORs the result with the pt or ct block.
It's a way to take any block cipher and turn it into a stream cipher with the power of XOR.
(I'm only going to ask this nicely once: cease and desist stalking and harassment.)
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.
You have a system of keys derived from a master key. Too many bytes encrypted with one key? Use a new key for subsequent writes.
(And for god's sake use a PBKDF to derive a master key from a password, don't memcpy() it directly.)
XTS is only useful for FDE, everything else should look for simpler constructions.
Maybe you need to read:
http://cactus.eas.asu.edu/partha/Teaching/539-CommonFiles/Cr...
Would really appreciated if you would know you're talking about and provide evidence before saying "it's wrong" or "it's bad advice."
Later: FWIW, it looks like the parent comment was edited after I wrote this.
Again, you're making accusations, shifting the conversation without providing evidence. Talking with you is pointless.
Second, KDF1 would be even slower.
Third, you still haven't explained how KDF1 or HMAC takes you from the master key, derived from the user's password, to several million per-sector keys. What's the relationship between the keys?
Fourth, deriving keys from other keys is potentially dangerous; it's something you avoid doing if you can.
Fifth, as the article mentions, one of the reasons nothing in the universe does this is that running the key schedule millions of times is itself pointlessly time-consuming.
Sixth, you're running CTR mode deterministically. As the article points out, you can't do that: every time you alter a sector, you'll be encrypting data under the same keystream. Higher-level code gets to use CTR because it can arrange to randomize it, but in sector-level crypto you don't get to store a nonce.
What's frustrating to me here is that you basically just made a bunch of stuff up, and then feigned offense that I wouldn't have taken this nonsensical scheme seriously. But that's what it is: nonsensical. Nobody generates individual keys per sector. The article covers this: you'd like to do that, but it's too difficult.
Hence tweakable ciphers.
Lodge objections with Liskov, Rivest, Wagner, and Rogaway, not me.
I'm not sure that everybody has developed the intuition that this is horrifically dangerous. Maybe point them to something like
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.
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.
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 = dataFurther, 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.
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.
"It's unreasonable to debate with an unreasonable person."
Bye.