Is there any way to have your disk/partition/file encrypted (in Linux or as a hardware encryption; no Windows here) in such way that it locks itself for say 10 minutes after say 3 failed unlock attempts?...

The idea is to have a somewhat shorter password to remember without sacrificing security.


Not the way you describe, so @Damon's answer is correct.

But if you don't mind waiting regardless whether you know the password or not, you can crank up the iteration time of cryptsetup/LUKS to a very large value, even to 10 minutes if you think you need that much. That way the "lockout" would always be in effect, regardless of your attempts.

cryptsetup --iter-time=600000 luks[Format,AddKey,ChangeKey] /dev/thing

However, I don't recommend you actually go that route. It's not very practical.

A good password is more important in any case. If you find passwords hard to remember, maybe you should heed this advice: http://xkcd.com/936/

That's geared to web passwords (where lockout actually works, until an attacker grabs the database). For disk encryption you might want to use more than just four random words.

But in general, a good password does not have to be hard to remember.

  • 1
    Hehehe, the --iter-time=600000 suggestion is a funny solution. Good one :-) – Damon Jan 28 '15 at 19:11
  • 1
    @wojtekjablonski if you use a cheaper hash function it will still take the same amount of time on your machine; it will simply use more iterations to compensate. – frostschutz Jan 28 '15 at 19:19
  • 1
    Of course, a determined hacker can divide your iter-time by the number of computer's he's willing to expend on hacking you - if you have iter-time set to 60000, and he has 1000 computers to spend on hacking you, that's the same as if you set iter-time to 60, so don't assume you can use a 4 character alphanumeric password in the belief it would take him years to crack it. – Johnny Jan 29 '15 at 1:40
  • 2
    There's weakness in that xkcd technique, especially when talking about an offline brute force. It's not a terrible technique, you just have to realize when using common words, then the entropy of each is much lower than what that comic represents. There's actually a couple githubs written specifically to crack those passwords. – AaronLS Jan 29 '15 at 1:43
  • 3
    @AaronLS - The xkcd comic assumes 11 bits of entropy per word, which is equivalent to a 2048 word vocabulary. The average 5 year old has an expressive vocabulary of 2150 words (by high school it's around 10,000 - 17,000 words), so as long as you have the vocabulary of at least a 5 year old, and don't just pull the passphrase from a few common words, the XKCD model holds true. The most important thing is to pick random words, not well known phrases. – Johnny Jan 29 '15 at 7:06


This is an entirely nonsensical endeavour. If you choose a password that is so easy that I might be able to guess it with 5 or 6 attempts, you might as well not use disk encryption at all.

On the other hand, a password that cannot be guessed in under half a dozen attempts and would trigger this "lock out security measure" is of no avail either.

An attacker who is only marginally clever will run an offline attack, that is he will read a few sectors and try to brute-force them with his own (massively parallel, multip-GPU) tool. He doesn't care whether you "lock him out" on the boot screen because he isn't using it at all.

Note that every reasonably modern disk encryption software uses an expensive key derivation algorithm which takes around half a second or so on your computer to actually compute the encryption key from your password. This is meant to slow down brute force attacks which would otherwise test billions of passwords per second.
But of course throwing a multi-GPU rig at the problem means you can still test a few thousand passwords per second. Given a dictionary-based test permutation, it is very optimistic to assume that an "easy" (read as: bad) password will hold an attacker back longer than a few seconds.

  • As to paragraph #1 of yours, I actually meant a 8-character non-dictionary password instead of a ~20-character. In this case it doesn't seem to be as "nonsensical" as you may call it. – jabol240 Jan 28 '15 at 18:52
  • 1
    As to paragraph #3 I took your answer as "it is not technically possible because unlock attempt frequency cannot be controlled from inside the encrypted data". Is that correct?... – jabol240 Jan 28 '15 at 18:57
  • 1
    An assumed random case-sensitive-alphanumeric 8-character password would have slightly less than 48 bits, which will be enough to hold back an attacker for a good while, if a good key derivation algorithm is used (one that takes, say, half a second). But of course random case-sensitive-alphanumeric means it's a pain to remember and to type again (unless you make it "not really random", at which point it's useless). – Damon Jan 28 '15 at 19:02
  • 1
    About controlling the unlock frequency as you call it, the problem is that the attacker will not go through that door at all. You can prevent your 5-year old sister from typing in one password after another, but you cannot prevent someone from reading a raw sector and trying a thousand passwords (or, well, millions or billions, depending on how complicated/easy the key derivation algo is) per second on a dedicated massively parallel machine. – Damon Jan 28 '15 at 19:05

No, that would not make sense.

A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because the only way to reach the system is part of the system itself.

A delay between attempts doesn't make sense for offline uses of passwords, for example to decrypt some data. It's impossible to implement because the way to reach the system is not part of the system itself, so the adversary can implement their own password checker. Furthermore the encrypted data can be replicated, allowing the adversary to make many attempts in parallel (as many as they're willing to spend on hardware). If the attacker wants to make 1000 copies of the data and attempt to decrypt them on 1000 computers as fast as these computers will go, nothing can prevent them.

You can slow down the adversary by making the password verification intrinsically slow. An encrypted volume uses a key which itself is encrypted with another key which in turn is derived from a password. (Some badly-designed systems excluded.) The derivation of the password from a key, if done correctly, is a key stretching function which is intrinsically slow — the fastest known way to derive the key from a potential password requires a large amount of computation. In a well-designed system, you can tune the amount of computation; for example, with LUKS, that's the -i parameter to `cryptsetup luks. A larger parameter makes verifying the password slower, both for you and for the adversary.

Credit cards can afford to use a 4-digit PIN because they're an online system: depending on the card technology, either the PIN typed by the user is sent to the bank for verification (so the bank's servers implement the 3-failures-and-you're-out policy by recording the card as compromised), or verified by the chip on the card (so the chip on the card implements the 3-failures-and-you're-out policy by storing a “card is compromised” flag in its persistent memory).

You can encrypt your data with a key stored in a smartcard, instead of using a key derived from a password. This lets you have a very short password (e.g. a 4-digit PIN) that isn't ridiculously easy to break. It has downsides, however. You need to have the card with you when you want to access your data. You need to have a card reader available where you want to access your data. You need to back up your key somewhere, in case you lose the card or it fails. If your computer has a TPM chip, this can serve the same purpose as the smartcard, with the difference that the card can be carried between computers (useful for removable drives or remote volumes) whereas the TPM is tied to a motherboard (more convenient if the encrypted volume is on an internal drive).

  • 1
    If you trust it, the TPM chip built into many computers, might fulfill a similar role as the smartcard you mention. – CodesInChaos Jan 29 '15 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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