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