Disk Encryption (LUKS) Fails on Very Long Passwords

Hi

so I wanted to update my password to something more secure. I chose a password with over 100 characters, passphrase to be precise. Now I got the issue that at boot-up I only got one chance at entering the password.
If I am wrong, the password prompt reappears; however, after entering the password again, the prompt disappears and does not come back. It does not matter if I type in the correct or the wrong password. It is just gone.
I tried with terminal-interface by pressing F-keys.
I’ve got the same issue. Only one try to enter password.
With a shorter password I have at least 3 tries.

Does anyone have the same issue or knows what it could be related to?
It has nothing to do with the hardware. I tried this on my old notebook and had the same beaviour. I wanted to try on my new one again.

Thanks for your answers :slight_smile:

After a certain password length you don’t get more security because you’re already beyond what current computers can break. Perhaps set a shorter (but equally secure) password:

If the issue disappears with a shorter password then it’s one of those edge-cases where it may not even be worth fixing IMO.

Well, it’s not just about length. It’s mainly about entropy. Some people choose longer passphrases because they’re easier to remember. I could have a paragraph-long passphrase, but if it’s a paragraph out of a book (or even just one someone might write), then it’s probably very easy to crack compared to a shorter, truly-random passphrase.

4 Likes

Since we’re talking about length and entropy, I’d like to double check with the experts here, which should also inform this user. I think 10 to 12 random high entropy by way of diceware words is enough to even stop future quantum computers. Would the experts here concur? If so then 60 to 80 characters is likely enough. 100+ probably too much.

I’m not a cryptographer, but we can see what they have to say about it. According to Bruce Schneier in Applied Cryptography (as quoted in [1]):

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38×10-16 erg/K, and that the ambient temperature of the universe is 3.2 K, an ideal computer running at 3.2 K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our Sun is about 1.21×1041 ergs. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

But that’s just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

He also wrote, in “Quantum Computing and Cryptography”:

Quantum computers promise to upend a lot of this. Because of the way they work, they excel at the sorts of computations necessary to reverse these one-way functions. For symmetric cryptography, this isn’t too bad. Grover’s algorithm shows that a quantum computer speeds up these attacks to effectively halve the key length. This would mean that a 256-bit key is as strong against a quantum computer as a 128-bit key is against a conventional computer; both are secure for the foreseeable future.
[…]
There’s one more future scenario to consider, one that doesn’t require a quantum computer. While there are several mathematical theories that underpin the one-wayness we use in cryptography, proving the validity of those theories is in fact one of the great open problems in computer science. Just as it is possible for a smart cryptographer to find a new trick that makes it easier to break a particular algorithm, we might imagine aliens with sufficient mathematical theory to break all encryption algorithms. To us, today, this is ridiculous. Public-key cryptography is all number theory, and potentially vulnerable to more mathematically inclined aliens. Symmetric cryptography is so much nonlinear muddle, so easy to make more complex, and so easy to increase key length, that this future is unimaginable. Consider an AES variant with a 512-bit block and key size, and 128 rounds. Unless mathematics is fundamentally different than our current understanding, that’ll be secure until computers are made of something other than matter and occupy something other than space.

Ok, so that seems to leave us with a few takeaways:

  • Grover’s algorithm effectively halves key lengths. 256-bit keys are effectively as strong as 128-bit keys against quantum computers, while 128-bit keys are effectively as strong as 64-bit keys against quantum computers, and so on.
  • In spite of this, Schneier thinks both 256-bit and 128-bit keys are secure for the foreseeable future.
  • When we start to consider threats that go even beyond quantum computers (e.g., aliens with advanced mathematics), then he thinks at least 512-bit keys would be secure. (Note that he doesn’t claim this is the minimum; he just provides it as an example of something that would almost certainly be secure even in that scenario.)

So, let’s assume we’re aiming for a 256-bit key size (with the effective strength of a 128-bit key against quantum computers). What kind of passphrase do we need to achieve 256 bits of entropy? According to the “password strength” Wikipedia article, 256 bits of desired passphrase entropy would require either 39 truly random ASCII characters or a truly random 20-word Diceware word list.

Ok, but the original question was whether a 10-12 Dicware word list would be sufficient. So, how much entropy would that get us? According to the same article, a truly random 10-word Diceware word list would provide 128-bits of passphrase entropy. Given that Schneier said that 128-bit keys (effective strength of 64-bit keys against quantum computers) should be secure for the foreseeable future, it appears that the answer to the original question is basically yes.

2 Likes

What an excellent write up. You’ve just helped me fill so many gaps in my knowledge about the matter, saving me likely a year or so of reading too. I truly appreciate it! And personally I’ll feel secure with with 10 words :slight_smile:

2 Likes

I actually clung to Passwords - Whonix.

As refered to by @adw, I chose such a long passphrase because it is way easier to remember, it is more secure (you can generate your own dictionary with crazy words - my opinion -) and I wanted a password already good for Quantum Computing (who knows what is brewing in the dungeons of some big tech companies or state research facilities).

What @adw did not highlight is that the entropy of your passphrase depends on the size of the dictionary you use.
So you cannot easily say that 10-12 diceware words are sufficient if you have a language with a smaller dictionary than english or just not a full - every word containing - dictionary at hand.
The calculations from security experts are that. They are professional calculations and do not necessarily consider every day life circumstances.

Guys I do not really get why somebody who is using a security orientated OS would tell me to take a shorter passphrase.
I just get around the 130 bit entropy.
Passphrases are in my opinion a way to better password security a lot compared to passwords like:“10aqpakfoeakdvm011”. Who can remember this?

LUKS is supporting accoridng to cryptsetup --help 512 characters of length. So my password with 100 characters is actually just 1/5 of the supported length.
I think every bug in LUKS or the implementation of it in Qubes is a matter to look into. If I only have one try to enter my password lets say bigger than 100 characters, it could mean LUKS is not integrated correctly or there is some bug in LUKS.
The limitation of being kicked after one try discourage people to use secure passwords.

Maybe someone got a test-machine (I unfortunatly got none) and has time to test this baviour.

If you trust the security of the involved hash functions to evenly map passwords to keys, you don’t need as much entropy as the key size. Actually if you don’t trust them, you might be lost even with very long passwords (Example: Hash function that maps every password to a key of ‘1’)…

@adw : You didn’t mention that keys are derived from a series of hash functions on the password and a password is never directly used in reasonable real-world crypto systems such as luks (it’s apparently called [key stretching]). So e.g. even a single character password would result in a 512 bit key for AES-512.

An attacker may try to brute-force that key at complexity 2^512 and on average succeed after 2^511 iterations. With a quantum computer it would be 2^(512/2) due to Grover’s algorithm.
Cryptographers generally assume 80-bit to be reasonably secure; so in theory a 80-bit key size (AES-128 as there’s no AES-80 or so) and a 160 bit key size for quantum computers (AES-256) suffices. Anyway using AES-512 is relatively cheap nowadays…

An attacker may also try to attack that single character (which makes a lot more sense) and compute that series of one-way hash functions for it. Usually those hash functions series are designed in a way that makes computation on a regular computer take a second or so and impossible to use rainbow tables, which also needs to be taken into account for brute force attacks. Actually it is still unclear whether quantum computers might improve the situation with those computations (possibly they do though).

Anyway [1] claims that 7 dice words are enough for 80-bit security and 13 words for 160 bit in quantum age. I didn’t check their maths though.

[1] Password strength - Wikipedia
[key stretching] Key stretching - Wikipedia

Side note: Key stretching also essentially means that it is rather pointless to use more password entropy than the key size.

Anyway I don’t see why there should be a limit on password length in luks. If there is, that should be fixed upstream.

FWIW, I never said that (nor would I). However, I do not know why you’re apparently being limited to 100 characters and have no idea how to help, so I didn’t really have anything useful to add on that front.

I wonder where the bug lies. Is there also a 100-character limitation in baremetal Fedora 25, for example? If so, then it’s not a Qubes-specific bug. On the other hand, if this limit exists only in Qubes OS, then it’s certainly our bug to fix. Perhaps you or someone else could do some more investigating to figure out where the bug should be reported.

Yes, there’s a lot I didn’t mention, because I make no attempt to offer a complete course of study in cryptography in the space of a single forum reply (not that I’d be qualified to do so anyway!). :slight_smile:

As I said, I’m not a cryptographer. I was just quoting some sources in an attempt to help him try to answer his question in a (somewhat) concise way.

But it doesn’t exist (yet), does it?

AES is currently defined only for 128, 192, and 256 bit key sizes:

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf#page=9

1 Like

Had not yet come across this page. Thanks for sharing.

You can always consider reporting this as a bug:

Although this may actually be a bug with LUKS so perhaps checking first with them would be good.

Hm you’re right about AES being max 256 bits in key size, my memory was wrong there.

Anyway my main point was that the size of the password space doesn’t need to be equal to the size of the key space to provide reasonable security.
So 80 bit of password space (or 160 if you fear quantum computers) is fine even if the key space is 256 bit or larger.

I felt secure with my ten word passphrase. 24 hours later I no longer feel secure. :laughing:

I have a feeling that’s going to be the weekly pattern of being part of this community. But I love it. Glad to be here.

1 Like

I would guess post-quantum security is a much lower concern than other stuff. Stuff like HW integrity is likely a bigger target. Check your threat model to understand what’s really important for you and focus on that. Don’t just define “security” as a general thing that you strive towards getting the max of.

1 Like

… for such password discussion I always like to bring up this meme

I did not mean to criticize your post. I just wanted to point out to that the context is bigger.

A simple and not complete explanation on how LUKS works can be found here: Unfinished blog post on Linux full disk encryption · GitHub
Really easy read.

So there is a bug which is probably related to using fedora 25.
Unfortunately I couldn’t test it directly on fedora 25 since my setup won’t boot the Live-ISO to install fedora 25.
I tested on fedora 32. There the bug is fixed.
I am creating a bug-issue on github right now for R 4.04 (LUKS decryption at boot - only 1 try when entering a password with more characters than screen width · Issue #6866 · QubesOS/qubes-issues · GitHub).

The bug is the following: If you enter a password that is longer than the screen width at your first try. You do not get a second try.

Your cartoon does not mention that if everyone were to be using passphrases 4 COMMON words would not be sufficient entropy.
Lets say you got 5000 words commonly used in the english language.
Log(5000) : log(2) * 4 ~ 49 bits of entropy.

Then it depends on the amount of words contained in the list you use.

It is a meme, it should be food for thought.

No one will stop you to make a 10+ word sentence, in two mixed languages with ASCII symbols.

Just keep in mind that many millions of crypto currencies trust random words as seed.

Conclusion:
Is it the most secure? No.

Is it secure and easy to remember / to type without typo? Yes.

Aug 30, 2021, 19:15 by qubes_os@forum.qubes-os.org:

Yes you are correct.

I think it is not even that hard to remember 8 words. Use that for a password manager and you are good to go. After that, any password breach is most likely not caused by brute-force but a server breach on the provider side or your machine being infected with malware.