TL;DR For random-seek block encryption, don't use XTS, use CTR.
It's simple. I like simple maths and code, it's less to screw up and less for implementations to screw up. For example, I don't trust EC or GCM, even if some people thinks they're the new hotness, because complexity creates more opportunities for obfuscation and puts the code further out of reach of the already few eyeballs actually (or not) looking at it.
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.)
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
No, rekeying does not solve that problem, not to mention which you've just handwaved a hard problem (varying the key over different sectors). That's doable (though it again doesn't fix the problem with your proposal), but the resulting mode isn't CTR.
This is a sequence of non-sequiturs, none of which respond to my comment. I'll make it easier for you:
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.
CTR isn't an OTP in the classic sense of OTP, because you rely on the security of blockcipher. For example, if you used blockcipher=single DES, the attacker can break the cipher by breaking single DES by brute force.
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.
Can I suggest you reread the article? I felt bad that I spent so much time on the mechanics of tweakable ciphers because people didn't really need to understand them to see why not to use XTS, but here you've vindicated all those paragraphs by stating the exact problem they solve, and did it be presenting an unsafe alternative to them.
Presumably the sector key is derived from the master key using one of the numerous fast KDFs, with PBKDF used only to derive the master key from the password. That's the obvious way to do it and midas007 explicitly mentions PBKDF as a way to generate a master key from a password with sector keys derived from that master key using some unspecified technique. You appear to have come up with your own obviously daft way of implementing the suggestion and then criticized that rather than the original proposal. Please don't do that.
Did you just propose running a KDF for every sector of the disk? Which of these numerous "fast KDFs" that derive related keys from master keys are you referring to?
Dunno, probably a generic HMAC-based one if for some weird reason I felt the urge to implement a crypto system that worked this way. Could probably use KDF1 or another KDF in that family too. (Honestly, there's probably no good reason to do things this way, it's just not obviously broken or infeasable.)
First, running an HMAC for every sector would be extremely slow.
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.
That looks like the definition of a symmetric stream cipher, not OTP. You're missing the part where the OTP keystream has to be truly random. The output of a block cipher in CTR mode is not truly random.
Indistinguishable from a PRF A good block cipher satisfied this property, otherwise it's not a PRF and insecure.
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.
No, you have your terminology thoroughly confused. An OTP is an information-theoretically secure cipher where the key is as long as the plaintext. The only relationship between a one-time pad and CTR is the XOR operation. Furthermore, the article you're responding to explains what's wrong with simple stream ciphers for disk sector encryption.
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.
No, malleability is not beyond the scope of which "mode" you encrypt something with. That's like saying that security is beyond the scope of which "mode" you encrypt with. People used to believe you could divorce confidentiality from integrity, back in the 1990s, but that turned out not to me true, due to adaptive chosen ciphertext attacks.
That's part of it, but this is something governments have to take leadership on right now. That will only happen with direct pressure. Waiting until it's the leading cause of death will be too late, because of drug development pipeline timeframes.
It doesn't have to be that way, and waiting around for "someone else to handle it" will likely lead to a Tragedy of the Commons.
Call your representatives [US: 0,1] or regional government representative (I just called my senator, and on hold for house rep now), tell them we need an emergency crash program to develop new, tightly-regulated antibiotics so that infection doesn't become the leading cause of deaths in 2025. Because it takes years and billions to develop new antibiotics, this is something companies will not pursue on their own initiative. If not, it'll be a return to the 19th century. Good luck with that.
You're not going to have new antibiotics without biotech or pharmaceutical companies helping.
The government needs to provide incentive for antibiotic research, right now regulatory and reimbursement issues are making the therapeutic area very unattractive.
Exactly. But because of the difficulty, time and capital requirements, this is something that can't be left to the market economics. It will be too late by the time we need them because of the years it takes to develop a single new drug. This is a "going to the moon" type thing that needs to happen if we intend to survive. Because that's what's at stake.
(1) You say it can't be left up to market economics, but two of the big hurdles to new antibiotic development are government regulations: (I) In the past the FDA was not very responsive to the resistance problem, if you had a new drug, you went through a normal review; luckily they have changed their approach recently (II) The way that Medicare and Medicaid pays for antibiotics doesn't encourage investment in novel agents
(2) I have to push back on the "going to the moon" type thing. This is more like we've already been to the moon and we need to go back and do something different. Drug companies know how to develop new antibiotics (not to say it's easy, but they have ideas) and they know how to get them approved. There are new discoveries all the time. We just need to create an ecosystem that encourages further investment.
Edge cases. The big picture is that it's not happening fast enough, which is why the government will need to step in and will need to assume a leadership role to push hard on this.
That's not going to happen. The gov't will change the regulatory and reimbursement environment but the heavy lifting will be done by academic and pharmaceutical researchers.
>But because of the difficulty, time and capital requirements, this is something that can't be left to the market economics. It will be too late by the time we need them because of the years it takes to develop a single new drug.
Isn't this exactly what people used to say about the food supply?
Nope. It is what it is: capital-intensive research that is hard and it takes a long time to come up with a molecule that will stop an infection without killing or disabling the patient. That can't be done last minute like in the movies.
FYI: One of the last-ditch antibiotics (I forget the name) has a side-effect of permanently damaging hearing. I have to basically yell at 95 yo grandmother for her to hear me. :)
I don't eat meat or consume animal-derived products for this reason. This is where the next pandemic is mostly likely to originate, and it's completely preventable.
Unless you also avoid meat for other reasons, wouldn't it be better to eat meat, but only from those farmers that raise livestock in humane, sustainable conditions (organic/free range/...)? That would increase competition and support their business models.
On a personal note, my mom is still under the weather, having stuck to three different courses of antibiotics for a simple nasal infection.
It's frightening when this becomes the norm, not the exception because we're basically running out of options by natural selection moving faster than research.
We need a crash program to develop antibiotics before it's too late.
I think you meant "someone gets privileged code execution," which is a sensible assumption. Even still, app-permission (less than privileged) code execution can still do damage like host malware, IRC dumpsites/bot control, diodes, tor relays, vandalize web properties, etc.
The only way to know that a system is no longer owned for certain is to reimage it to a known good state. Doing anything less is tons of work, and unlikely to catch everything (rootkits, backdoors, hidden services, replaced system files, etc.). Even when running HIDS, HIDS cant be trusted because rootkits can hide things from it because it's running from the system with a possibly infected kernel. So, it turns out reimaging is less work and more trustworthy if the box is rebuilt and the 'sploit can be mitigated before bringing it online to the outside world (build and patch offline to avoid getting re-owned).
While I agree in principle that when owned one should start from scratch, my advice would be to learn something. Often I am asked to analyse attacks and I now have a collection of about 15 malware scripts that not only show me the intent but they are also useful (and remarkably well coded) for my daily admin tasks.
So, fresh start but at least get something out of it!
"and the 'sploit can be mitigated before bringing it online to the outside world"
You should read more carefully.
Also, keeping people waiting without an ETA for a down service because you're learning isn't going to result in happy customers.
Furthermore, whomever is running these boxes needs to deploy NIDS and HIDS and properly secure their boxes, because clearly they don't understand what an attack surface is.
Disagree, both in spirit and to the letter; for starters, I'm pretty sure there's still validity in a very long blog post I wrote about NIDS back in 1998:
[0] http://techcrunch.com/2014/02/15/was-y-combinator-worth-it/