Jeff Soules escribió: > As Ron said, the problem you're describing is a little bit different > from the one the man page talks about. > >> The most intrusive attacks, where an attacker has complete control of >> the user's machine (and can therefor modify EncFS, or FUSE, or the >> kernel itself) are not guarded against. Do not assume that encrypted >> files will protect your sensitive data if you enter your password into a >> compromised computer. How you determine that the computer is safe to >> use is beyond the scope of this documentation. > > Seems to me that the man page is talking about two situations: > > #1. Someone has rooted your box. In this case, your encryption can be > bypassed, because unless your secret passphrase is actually an entire > RSA key, the password is just a gatekeeper and everything needed to > decrypt the fs is on the box. A (sufficiently clever) attacker with > root (and enough time) could modify the EncFS program itself to bypass > the password check and just decrypt your files. > > #2. Your box is keylogged, or (for some unknown reason) you put in > your decryption password on a compromised/keylogged other box. This > isn't strictly an offline attack, it could happen remotely if the > password is compromised. I suppose you could get around this by > automating the way your fs password is input (although if it's > automated input over stdin, couldn't a properly designed keylogger > still eavesdrop on it?), but that's kind of missing the point, which > is if situation #2 happens, you will soon find yourself in situation > #1. There, the real questions to ask are "how do I avoid getting a > keylogger" and "how do I catch a user account compromise before the > attacker can gain root." Taking steps in response to those questions > will make you much more secure across the board. > > > If you're simply worried about protecting your filesystem from offline > attacks, i.e. someone has physical access to your computer without > having rooted it or whatever, then (as always with security) it > becomes a question of how good is good enough. How long can someone > sit at your computer trying to log in before it locks out for half an > hour? How long before you (or someone else) comes back to stop them? > Having logged in, how long before they manage to decrypt the > filesystem without using EncFS? Etc. We're starting to talk about a > very dedicated attacker at this point, who must have a compelling > motivation for attacking your box specifically; these aren't > government secrets, right? At any rate, in this kind of situation, > other security considerations and means of attack > (http://xkcd.com/538/) start to come into play. In fact, the main > scenarios I can imagine are either that you're trying to keep personal > files secret from a prying but technically skilled family member, or > that you're protecting a corporate environment from some kind of > industrial espionage (although again, in the latter case I think > you're more vulnerable to social engineering attacks than strictly > technological ones). > Though I would wonder if, in those scenarios, having the password > automatically input from an SD card or something might actually > decrease your security. If you're talking about offline attacks, > that's someone with access to the computer's physical environment (and > who may even have seen you put in the SD card while you mount > encrypted FSs). A non-compromised, keyed-in password would actually > provide more protection in that case than an SD card that's sitting on > your desk somewhere and that any joe could plug in. > > > After all that, if this problem still seems compelling to you, then I > suppose the best situation would be for you to have an SD card or > whatever, kept secure and separate from the box, that feeds the actual > encryption key into the system, with that key not being stored locally > at all. Ideally you would also have some kind of second password > check required to get the program to actually use the RSA key, so you > can depend on both something you have and something you know. I've no > idea how to implement this technically; I don't see a facility in > EncFS to do anything like this. Also, this setup makes your data > brittle; if your SD card gets wet or zapped, your filesystem is gone. > There's always compromises between security and convenience, and > security and resilience of data. > > And, joy of joys, make sure you store your backups somewhere nice and > secure. With your EncFS setup you probably want to store the backups > of the encrypted filesystem away from all the others, so that someone > getting ahold of them has to crack the actual encryption rather than > just hunt around for the key.
Ok, thank you for your help. I've read it carefully. Now imagine the worst situation, that a friend wants to protect his data from his corrupt dictatorial government, and he doesn't want to directly make the question here, because he is afraid. For email, there is PGP, I suppose it is good enough, right? But he uses a computer for writing those emails, for writing papers which may be compromised, he has some forbidden digital books like the Universal Declaration of Human Rights (or whatever it is speelled in english), etc. Imagine that he is actually in the risk of having the police to enter into his house and get his computer. Then my question is: is EncFS good enough to protect his data? I think the SD with stored password is a good solution. While he is not in the house, he can carry the SD or have it hidden somewhere. While he is in the house, and police enter, he might have enough time to probably destroy the SD and turn off the computer. What would you recommend in this imaginary case? Also, I have seen that encfs support up to 2048 characters for the pass phrase. Is it better to have a very large random pass, or it is irrelevant at some point? And which is better, Blowfish or AES? Thank you. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
