Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to encrypt my filesystem with encfs, but I don't know how long my password should be.

I'm gonna be using AES 256, with blocks of 4096 bits.

How many guesses per second can I expect an attacker can make on files encrypted with that?

I'm worried that this might depend on the size of the smallest encrypted file.

Any thoughts?

share|improve this question

closed as not constructive by Zoredache, EEAA, Dave M, Ward, Tom O'Connor May 24 '12 at 10:20

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I don't think you understand how filesystem encryption works. – EEAA May 23 '12 at 20:06
Who are you worried about stealing your drives? The NSA, or a typical burglar? – Zoredache May 23 '12 at 20:06
@Zoredache Lol no, not the NSA. But not a typical burglar either, someone with some level of expertise in cryptography. – HappyDeveloper May 23 '12 at 20:11
@ErikA Would you mind elaborating please? – HappyDeveloper May 23 '12 at 20:12
BTW, you have seen the required posts right? and – Zoredache May 24 '12 at 0:19

Check your password/passphrase. The bits of Entropy should be approximately half of what your encryption algorithm is. If you're using AES-256, you'd want a passphrase with about 128 bits entropy.

Using AES-256 is overkill by the way. AES-128 is pretty much overkill, depending on what timeframe we're working with (128 should be good for years to come, 256 for a decade or more, both guessing).

Note: the Rumkin test has been hacked up quite a bit because it doesn't recognize obviously bad passwords. For instance, "Password1" is given a "Reasonable" rating; it's one of the most commonly used passwords, so it's the first thing anyone would try. Be reasonable about your password choice and the Rumkin test should give you fairly accurate results.

share|improve this answer

I'm no cryptography expert, but AES isn't dependent on the sizes of files, nor the structure of the filesystem at all. Everything is encrypted block by block (whose size is a fixed number of bytes), and the algorithm should run in constant time for whatever data is in that block. Truecrypt can run a benchmark, telling you how many iterations of each of their supported algorithms run on your processor in a fixed amount of time. For example, WPA2 encryption, used in WiFi, requires something like 4,096 rounds of encryption for a single key/guess/authentication attempt, so brute-forcing these types of keys is extremely slow.

Assuming that AES encryption itself isn't broken any time soon, your goal becomes to pick a password with sufficient length and complexity that it cannot be brute-forced. There's lots of advice out there on how to pick a good one, but generally speaking, the longer the password, the more secure it is. Some pro tips:

  • Anything less than 8 characters is horribly insecure
  • Do not use dictionary words, or c0mm0n v4ri4nt5 th3r30f
  • 12 characters or more seems to be reasonably secure in my opinion, but don't forget that computing power (especially GPU power) is growing exponentially, so it could be easier to crack in a decade or more
share|improve this answer

This is "simple" in its most basic form:

1) How long does the information need to be protected? 2) At what rate can the attacker guess passwords?

But of course defining those things is hard. Only you can say #1, but your answer is probably not a thousand billion years, so that gives you somewhere to start.

As for #2, attackers have wildly varying amounts of horsepower at their disposal. Like @Zoredache said, you have to decide what level of attacker you're worried about.

If you're worried about your roommate cracking it, and the information only needs to be protected for a couple of years (i.e., it's of no use after that time anyway) then just pick a password that's as strong as any other place would recommend (see the XKCDs mentioned above for a good summary).

If you're worried about the FBI cracking it, and want it to be protected until you're dead, you're in a whole different ballgame. These kinds of "attackers" will have dedicated, special-purpose hardware at their disposal that can rip through hundreds of thousands or millions of passwords per second. And that's today. Ten years from now... you get the point.

But, since we're talking filesystem encryption, this is all to presume that the attacker has gotten ahold of your drive, knows what software and algorithm has been used to encrypt it, and cares enough to do so. So if you keep your system in a safe environment and use something such as TrueCrypt's hidden volume feature, you've already greatly mitigated the risk. Pick a strong algorithm, such as AES256 as you've mentioned, change the key once every year or two, pick a reasonable passphrase and, unless you're doing something highly illegal or sensitive, I wouldn't lose any sleep over it.

share|improve this answer

Hard drive encryption usually encrypts your whole drive, so noone sees the files or the filesystem, but just one big encrypted binary blob.

The password should be as long and as complex as you can remember.

more info about disk encryption here

share|improve this answer
Maybe that's not what I'm doing then. When I go to my .encrypted folder, I can see one encrypted file for each original file, which is good because I wan't to synchronize them with a cloud storage service like Ubuntu One, reuploading only the files that changed, and not the whole thing. – HappyDeveloper May 23 '12 at 20:18
About the password, I can do what it takes. I usually wouldn't be able to remember a 16 random characters string, but if I learn that less than 16 won't be secure, I can try. – HappyDeveloper May 23 '12 at 20:21
maybe you should specify which encryption software you are using. Password length is the only variable here, not the filesize. No mather how large/small the file is, your security depends on the password length/complexity (and of course if the encryption schema is implemented correctly) – mulaz May 23 '12 at 20:21
I said I'm using encfs – HappyDeveloper May 23 '12 at 20:22
@ErikA - I've become a huge fan of long but simple passwords, like mydogatemyhomeworkbutwhatever - virtually impossible to brute force because of the number of characters, and easy to remember. – Mark Henderson May 23 '12 at 21:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.