We're in a semantic rut here. Like I said way upthread: I'm not trying to litigate the term "Evil Maid". I'm pointing out that Truecrypt+Dropbox is vulnerable to use-tamper-use attacks in ways that physical disk encryption isn't. Authenticated encryption rules these attacks out, because there is no way to fail anything but completely when modifying ciphertext on the stored image. Call the attack whatever you'd like; I've clearly mentally generalized the Evil Maid idea in a way that you haven't. Maybe I'm giving Joanna Rutkowska too much credit (but I doubt it :)
Regarding "multiple access to the ciphertext" --- you will indeed brute force 16 bytes, but you won't be trying to find a 128 bit needle in the haystack; you'll be looking for 128 bit blocks that happen to have a mix of innocuous bytes --- of which there will be many possibilities --- coupled with the opcode you want, and you'll have the bytes trailing the previous block and the bytes leading the subsequent block to play with as well to narrow your search. The attack will look a little bit like the byte-at-a-time attack on ECB.
I think that attack is significantly more plausible than you think it is. Apparently, so did Ferguson, since he brought it up ("Code modification attacks") in his NIST objection.
My issue with semantics is not that you're generalizing the notion, but rather specializing it. The "tamper" part of use-tamper-use in Evil Maid refers to the entire system, whereas you insist on tampering with only the ciphertext.
I'm still skeptical about code modification. The access the attacker gets is not really an oracle as in your byte-at-a-time scenario (I take it you're referring to the one from your crypto challenges), they can only observe the decryption output in a very indirect fashion. The number of potentially useful "needle" configurations is also hard to tell, you'd need to get alignment right and produce valid opcodes throughout the block etc. And also how many tries would the attacker get in reality? The executable would need to be reloaded for each one of his tries.
But more fundamentally, I find the whole scenario unlikely. To get there in the first place would require the user to sync their system partition with Dropbox. I think it's fair to say that will almost never happen. And if we're talking about a physical repeated-tamper attacker, well the Evil Maid (the original (TM)) is a much easier option for him.
If you store an image with executable code in it on Dropbox via Truecrypt, how many times will you potentially run it out of that image?
Again: we are talking about properties that cryptographically sound systems simply don't have. And if you're using Dropbox as your backing store, and not a physical drive, there is no reason to accept those properties!
If I store a program on Dropbox, I might run it many times. Thousands? Millions to be generous? But if the attacker has to do a brute force search which relies on me executing each different tampered version of the program, that's probably too small of a number.
The reason to accept sub-optimal properties in this case is convenience. Truecrypt is popular and has a nice interface. Using it with Dropbox gives much better security than not using it with Dropbox. It's not perfect, but I still don't think we have any practical attacks against such a scenario.
I agree that having stronger crypto there is however possible and desirable.
Comments
We're in a semantic rut here. Like I said way upthread: I'm not trying to litigate the term "Evil Maid". I'm pointing out that Truecrypt+Dropbox is vulnerable to use-tamper-use attacks in ways that physical disk encryption isn't. Authenticated encryption rules these attacks out, because there is no way to fail anything but completely when modifying ciphertext on the stored image. Call the attack whatever you'd like; I've clearly mentally generalized the Evil Maid idea in a way that you haven't. Maybe I'm giving Joanna Rutkowska too much credit (but I doubt it :)
Regarding "multiple access to the ciphertext" --- you will indeed brute force 16 bytes, but you won't be trying to find a 128 bit needle in the haystack; you'll be looking for 128 bit blocks that happen to have a mix of innocuous bytes --- of which there will be many possibilities --- coupled with the opcode you want, and you'll have the bytes trailing the previous block and the bytes leading the subsequent block to play with as well to narrow your search. The attack will look a little bit like the byte-at-a-time attack on ECB.
I think that attack is significantly more plausible than you think it is. Apparently, so did Ferguson, since he brought it up ("Code modification attacks") in his NIST objection.
My issue with semantics is not that you're generalizing the notion, but rather specializing it. The "tamper" part of use-tamper-use in Evil Maid refers to the entire system, whereas you insist on tampering with only the ciphertext.
I'm still skeptical about code modification. The access the attacker gets is not really an oracle as in your byte-at-a-time scenario (I take it you're referring to the one from your crypto challenges), they can only observe the decryption output in a very indirect fashion. The number of potentially useful "needle" configurations is also hard to tell, you'd need to get alignment right and produce valid opcodes throughout the block etc. And also how many tries would the attacker get in reality? The executable would need to be reloaded for each one of his tries.
But more fundamentally, I find the whole scenario unlikely. To get there in the first place would require the user to sync their system partition with Dropbox. I think it's fair to say that will almost never happen. And if we're talking about a physical repeated-tamper attacker, well the Evil Maid (the original (TM)) is a much easier option for him.
If you store an image with executable code in it on Dropbox via Truecrypt, how many times will you potentially run it out of that image?
Again: we are talking about properties that cryptographically sound systems simply don't have. And if you're using Dropbox as your backing store, and not a physical drive, there is no reason to accept those properties!
If I store a program on Dropbox, I might run it many times. Thousands? Millions to be generous? But if the attacker has to do a brute force search which relies on me executing each different tampered version of the program, that's probably too small of a number.
The reason to accept sub-optimal properties in this case is convenience. Truecrypt is popular and has a nice interface. Using it with Dropbox gives much better security than not using it with Dropbox. It's not perfect, but I still don't think we have any practical attacks against such a scenario.
I agree that having stronger crypto there is however possible and desirable.