8

I am using keepass for securing passwords. I have a reasonable password, but if someone got hold of the file I am sure eventually they could brute force it.

I was thinking of using a key file as well, but as this would likely be stored along with the keepass file if someone were to steal my phone or laptop, it would not increase security. (not to be confused with this question which is worried about key loggers)

I was thinking then of generating 1000 key files to store along with the data file. Only one of which would be the real one that was used. Figuring that it would increase security as if someone was trying to brute force they would have to try password/key file combinations. Making brute forcing a few times more difficult.

Is this a correct assumption, or would it be fairly easy to deduce the key file from the encrypted store?

Community
  • 1
Jeremy French
  • 537
  • 5
  • 12
  • 2
    File access time :) would indicate which file is the one :) – damiankolasa Nov 26 '12 at 10:42
  • It would only indicate it if you'd recently accessed the file. Reads are also destructive w.r.t. the in-memory file cache, so you'd have to guess right early on, or the cache would be tainted. – Polynomial Nov 26 '12 at 10:46
  • 2
    Yes, eventually they could brute force it, but you might want to consider that eventually in this context is measured in the [millions of years](http://security.stackexchange.com/questions/8476/how-difficult-to-crack-keepass-master-password). – Graham Hill Nov 26 '12 at 10:50
  • 4
    To increase resilience to brute-force attacks you can increase the number of transformation rounds in KeePass in Database settings. Default is 6,000 rounds, I think, but you can increase it to 5,000,000 safely (~1s delay on database save on my computer). – Matrix Nov 26 '12 at 11:44
  • Could you clarify what your intention is? Do you want to generate 1,000 key files *to be used* with KeePass (I'm not sure, but I believe KeePass permits multiple key files) or do you want to hide one (or a few) key files among 1,000 potential candidates? There may or may not be some confusion here as to which you're suggesting. – Iszi Nov 26 '12 at 14:57
  • I am suggesting the latter. I'll try to clarify. – Jeremy French Nov 26 '12 at 14:59

5 Answers5

8

The choice of the key file among 1000 possible files, assuming that you can do it perfectly (e.g. the choice does not leak through access times), is equivalent to adding three digits at the end of the password. Adding three digits means remembering (beyond the password) a three-digit number, which is the exact same memory effort than remembering which of the 1000 key files to use.

Therefore, instead of using your key files, just append that extra secret data (the three-digit number) to your password. This will be at least as secure as your key files (and probably more secure, because your choice of file will probably leak in some way) and much less cumbersome to use.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
7

The needle-in-a-haystack method you're employing is precisely what I do with TrueCrypt. There are about 600 key files in a directory on a flash stick, and ~10 of them are used.

The flash stick has a hardware read-only switch, which prevents the OS from updating the "Last Accessed" metadata. Keep that in mind if you're using a writeable medium for storage - the key files you access will (likely) be given away by the access date. I've also added some extra "chaff" to this by randomising the created / modified / accessed dates on the files, to make all dates completely untrustworthy.

This makes it very difficult to find the right key files - 1,545,269,050,000,000,000,000 potential combinations, assuming 10 chosen from 600 files, if order doesn't matter and any one key file can only be used once. Each combination must be tried for every potential password, making such a brute-force completely infeasible. As long as you're using random key files of sufficient size (I usually use 4kB or more) there's no feasible way to brute-force the content, either. The key is (usually) generated by a hash of the file content, or a composite of those hashes if more than one key file is used, combined with the hash of the password. Note that "hash" could mean a simple hash like SHA256, or the output of a key derivation algorithm like PBKDF2 or bcrypt. As such, computing the key without the keyfiles is impossible. Conversely, it's impossible to identify the keyfile from the volume, since you'd need to know the key to deduce such a thing.

To address the potential cache timing attack mentioned in the comments by fatfredyy - this is highly unlikely. The proposed attack involves reading various files and comparing their access times. A recently read file should read faster than the others, since it'd be in the cache. However, read times from disk are noisy on hard disks (seek times from unknown current sectors make things interesting) and accessing the cache has a Heisenberg effect - reading a file will likely load it into the cache, and potentially corrupt the integrity of the cache in terms of potential for timing attacks. A similar problem occurs on SSDs, which employ relatively little read caching and a lot of write caching. In some systems, you may find that sequentially reading files in a directory will result in later files being prefetched, further complicating the timing attack. Short of physically extracting the hardware cache data from the drive, I don't believe this is feasible.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
5

Defense in depth is rarely a bad thing, but I'd challenge that having multiple certificates to work from really doesn't add much to your security and adds a lot to the overhead. Generally the best cryptographic mechanisms increase difficulty exponentially for a linear effort, ie, adding one random, alphanumeric/symbol character to a password makes it over 80 times more difficult to guess. At that rate, adding two characters to your password makes it 6400 times harder to guess which is already more added difficulty than your 1000 key files from a brute force attack on the password.

That said, your approach does still have merit if they attempt to attack the key file directly through some weakness discovered in the key file itself, but if that magnitude of an issue is found in the key storage, it is likely time to consider the key store invalidated in its entirety if you want to maintain a high enough level of security to consider the time to break the file encryption a threat.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
4

Why don't you store the key file on a usb key ? If someone stole your laptop they would still need the key. If you do that you have a two factor authentication.

null
  • 1,193
  • 6
  • 16
  • A good suggestion, but I don't see anything here that is actually addressing the posed question. The OP seems to be concerned that, if they are given access to the encrypted store and the keyfiles (such as if an encrypted laptop is kept in the same bag as the USB drive that has its keys, and the bag is stolen), an attacker might be able to deduce the keyfile based on information available from the encrypted volume. – Iszi Nov 27 '12 at 13:50
1

If you use an encrypted home directory (for example) and take other local security measures then you can deny the attacker access to your keepass database completely. If you neglect your local security then someone could install a keylogger (software or hardware) or a rootkit which will tell them which keyfile you're using and potentially your master password.