John Adams: > On Sun, Jan 6, 2013 at 1:47 PM, Jacob Appelbaum <[email protected]> wrote: > >> I generally agree that the data should be encrypted, though I think it >> should also be authenticated and integrity checked before it is actually >> used. >> > > If this level of paranoia is relevant to you, then maintain multiple > offline SHA, MD5, and other checksum formats before use.
Dropbox accounts have been compromised in myriad of ways. They have an architecture that allows for content tampering without detection. I think it is justified and not even remotely paranoid to ensure that files stored with Dropbox are manually integrity checked or that certain kinds of files are used so that users have integrity checking *before* decryption. This says nothing of possible SSL/TLS issues - do they even have client side pinning of certificates? To dismiss my concern as paranoia is neither technically reasonable nor using the term correctly. To quote Google define: par·a·noi·a /ˌparəˈnoiə/ Noun 1. A mental condition characterized by delusions of persecution, unwarranted jealousy, or exaggerated self-importance, typically worked... 2. Suspicion and mistrust of people or their actions without evidence or justification. A user in Syria is well worth attacking and we indeed see targeted attacks for such users. That clearly cancels out the claim of paranoia. I'd also say that the Syrian people are not alone in their concerns of targeted attacks. Exposing a user's kernel to an arbitrary disk for mounting is extremely sketchy. I'd wager that an attacker could do some serious damage before the user even expects to type in a password. There have been security issues about this in the past and I think it is reasonable to guess that it isn't an isolated incident: http://support.apple.com/kb/HT3549 Which says the following about Disk Images: "CVE-ID: CVE-2009-0150 "Available for: Mac OS X v10.5 through v10.5.6, Mac OS X Server v10.5 through v10.5.6 "Impact: Mounting a maliciously crafted disk image may lead to an unexpected application termination or arbitrary code execution "Description: A stack buffer overflow exists in the handling of disk images. Mounting a maliciously crafted sparse disk image may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue through improved bounds checking. This issue does not affect systems prior to Mac OS X v10.5. Credit to Tiller Beauchamp of IOActive for reporting this issue. Please don't call my concern paranoia. It isn't paranoia, it is an abundance of caution based on very specific public data. > > It would be trivial to script this outside of Dropbox's scope. > It isn't usable and thus it is unlikely to be practically used. It seems that this is a property of that a specific disk format should have and in my view it should fail closed if the file isn't what it seems. That second part is perhaps "just" a security UX issue. > >> I also think most disk images are not actually that difficult to brute >> force - I was involved in a project to perform FileVault bruteforcing >> accelerated by an FPGA a few years ago. With a modern GPU, I think >> things are pretty slanted toward the attacker. >> > > Saying that it's possible to break all encryption, all the time, is a > non-answer and doesn't address practical uses of cryptography. It also > creates an environment of fear for casual users. In the case of pure AES > (and not putting reliance on flaws in the implementation of systems like > Filevault), a reasonable attack on the algorithm still doesn't exist. (see: > http://www.schneier.com/blog/archives/2012/03/can_the_nsa_bre.html) > I'm not really making a general claim about crypto; sure lots of stuff in the long run is possible to be broken and there is a lot of speculation about the state of things today, etc. Rather, I'm saying that the attack surface of using encrypted disk images is multifaceted. Merely encrypting a file or disk image is only part of the solution and probably a dangerous one, I think. Without integrity checking as part of the format, the attack surface is way larger than is reasonable. There is also the major issue of the user space tools or the kernel itself being flawed when operating on a malformed disk image, as mentioned above. When the security UX is "click here, wait for password prompt" - I think it is game over if the user does open the disk image. > What the user needs to do is to measure acceptable risk and weigh that > against the encryption system being used. It's also relevant to know the > validity of the information and the required amount of time it takes to > break the file. If you said 'meet me here next week' and it takes three > weeks to break AES-256, then I don't really care if you find out where I > was weeks ago. > Forward secrecy is important and so is deniability. Generally one doesn't realize they need it until they wish they'd had it all along. That is why, like integrity, we should just design these properties into the file formats, network protocols, and so on. Obviously some things don't fit the mold but just because we don't want them now doesn't mean they wouldn't be handy later. Sometimes we have to plan ahead for generally unlikely outcomes. As an example, if the entire thing relies on TLS without a forward secret mode, I can imagine a reasonable attack. The attacker could wiretap a target and then later decrypt the TLS session by getting the long term key from Dropbox. Then the activist can be confronted and asked to decrypt the disk image that was downloaded. If the attacker is sneaky, they might even try to replace the image with a malformed one as stated above. > >> In this - I rather like what I've read about SpiderOak but I haven't >> seen a totally free implementation of the client or the server side... t > > > I haven't looked at it, but I'd like to. > This is where they make some interesting claims: https://spideroak.com/engineering_matters Overall, it seems to suggest that it would reduce the general attack surface. As one won't be presented with malformed disk images even if one enters the proper password unless the attacker already had the passphrase in question. All the best, Jake -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
