3

Imagine confidential information (certificates, keys, whatever) stored on an LUKS encrypted backup disk containing for example an ext4 file-system. AFAIK such a device contains a key file which is in turn encrypted with some pass-phrase. Suppose the secret pass-phrase was created using the utility:

pwgen -s 16

to get some semi-random string. For example "Z4sp9gmW47R8K0sy" After studying the cryptsetup FAQ I believe this should provide 94.4 bits of entropy and that should be enough to sleep well for the time being.

Imagine some such disk gets stolen or copied and some evil attacker is willing to spend reasonable resources to crack this media open.

How difficult will this really be?
Is the data really safe as long as the pass-phrase is not leaked (compromised) by other means?

  • Same question here on Ask Ubuntu – ztk Dec 14 '15 at 16:07
3

If we assume, as per your question, that the pass-phrase can not be obtained by a keylogger (or other malware), social engineering, using a cold boot attack, or by other means, (and is sufficiently long) I would say the data is secure. It should be noted though, that an adversary would likely try to obtain the key in the above mentioned ways, so you would need excellent operational security to make them use a brute force attack.

By default, the data is protected by the following algorithms:

The built-in default for cryptsetup versions before 1.6.0 is aes-cbc-essiv:sha256 with 256-bit keys. The default for 1.6.0 and after (released 14-Jan-2013) is aes-xts-plain64:sha256 with 512-bit keys.

Source: https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption

At this point in time, I do not believe there are any known vulnerabilities to help bypass the data protection on LUKS encrypted drives. (see https://askubuntu.com/questions/102271/are-there-any-known-vulnerabilities-to-ubuntus-full-disk-encryption-feature) So long as this remains true (and the key can't be obtained in other ways), attackers would have to use brute force attacks.

Brute force attacks

Brute force attacks are not particularly difficult to run - you attempt the pass-phrase over and over again until it succeeds. There are tools available that are designed to do just that. So the difficulty is not in the attempts themselves, but in getting it done in a timely manner.

Attackers attempt to optimize brute force attacks by trying more common/popular pass-phrases first, but at some point it comes down to chance. If the pass-phrase you use happens to be one of the billion or so most popular, then it could be broken quickly.

Even if the pass-phrase is unpopular, there is the chance that it could be the first guess made after the "popular" pass-phrases are attempted. The chance of that occurring (leaving in the "popular" passwords*) is

1 in (lowercase+uppercase+numbers)^(number of characters)
1 in (26+26+10)^16
1 in 47672401706823500000000000000

So it's unlikely, but could happen. For a probability comparison, feel free to check your odds of getting hit by a falling satellite, or lightning.

*Note: As you can see, removing the billion most popular passwords from the above makes a difference less than the number of significant figures my calculator has. So their inclusion shouldn't cause too large an error.

Luck, or the use of a popular password, could allow a brute force attack to complete in a timely manner. Reducing the number of passwords being guessed is also quite helpful (eg. knowing it's length, the types of characters used, how it was generated, etc.). If, however, the attacker is not particularly lucky, they might have to try 50% of the pass-phrases to succeed. It is suggested here:

https://www.eetimes.com/document.asp?doc_id=1279619

that you can make 10^13 guesses per second on a supercomputer. That supercomputer would thus take

23836200853411800000000000000/10000000000000 = 2383620085341180 seconds
(75532362 years)

to try 50% of the possibilities. I imagine 75.5 million years of supercomputer time is fairly expensive due to electricity use and such, so probably doesn't fit your definition of "reasonable resources". Not to mention we assumed a pass-phrase without accented characters, punctuation, or special characters.

As such, I consider data protected by LUKS to be safe so long as there are no weaknesses found in the code and the pass-phrase is sufficiently long, unpopular, and cannot be obtained by other means.

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.