E.g. If the user is super-paranoid, or has super-secret encrypted info, they should double the size of their diceware passphrase due to the threat of PQCrypto and halving of the key size because of Grover’s algorithm?
So, if they assume quantum computers exist already or will soon, create a 14 word passphrase, assuming the entropy is halved to around a 7 word passphrase?
I don’t care about the math, just the practical application. (we can footnote the crypto guy)
If that is true, we add another column to that table e.g. “Post-quantum Security”, showing “Yes”, “No” etc based on assumed halving of key size.
You must care about the math because a probable solution is to create a larger list that diceware can choose from and hence increasing entropy without the need to make passphrases longer.
Check my quantum edits are correct here. I note your point re: longer word lists etc also. Confusion is two possibilities about Grover’s algorithm:
a) Halves entropy bit size (like I’ve shown in edits below); or
b) Halves total time to find key (which means only halving those bruteforce estimates in the column, which means doesn’t look anywhere near as scary)
american-english-insane a wordlist available in Debian.
We could ship a slightly modified/edited copy because it needs to be renamed to wordlist_en_american_english_insane.txt for diceware to recognize it and it must be dropped in the /usr/lib/python2.7/dist-packages/diceware/wordlists/ directory.
Excluding the few dozen Germanic words with special letter notations at the end, we have a total of 650,601 words. We would need to remove these words because we assume a regular Latin keyboard.
(EDIT: or maybe just edit them to have regular characters in there place and keep them.)
log (650,601) / log (2) = ~19.31 bits per word
256 / 19.31 = 13.25 words
That’s pretty decent considering there’s a law of diminishing returns at play here. A list of 10 million words gives only 23.25 bits of entropy per word. 1 billion: 29 bits. A latter sized leaked password database is found as a multi GB txt (north of 10GB) file on cracking wordlist sites making its size cost prohibitive. 13GB (4.4gb compressed) - WPA WPA2 Word List - 982,963,904 Words - Everything Else - Hak5 Forums
I admit some of the words are rather complicated compared to the short list. Is having to memorize 5 more easy words better than a shorter passphrase with some potentially difficult words?
Debian -- Error is a dictionary. Not a wordlist for diceware. I guess there wouldn’t be diceware wordlists if dictionaries would do. Problem with dictionary probably is that it contains a lot of very very short words. Not so in a diceware wordlist.
diceware developers should be consulted to make sure using that wordlist is a good idea.
That would be a bug to be reported against diceware.
As far as I understand, the prefix problem applies either way. AirPort / PortAble are almost equally easy to crack. These two words give only the entropy of one word plus a bit more through capitalization.
I guess that answer will vary greatly between individuals.
The result is our own list of 7,776 words [.txt] suitable for use in dice-generated passphrases. The words in our list are longer (7.0 characters) on average, than Reinhold’s Diceware list (4.3 characters). This is a result of banning words under 3 characters as well as prioritizing familiar words over short but unusual words.
Note that the security of a passphrase generated using either list is identical; the differences are in usability, including memorability, not in security
However these lists are designed with typing easiness and memorability in mind. So I’m not sure screwing around with them is the best thing to do.
As far as LUKS FDE is concerned it uses PBKDF2 for hashing an reiterating the input of a passphrase - creating a speed bump to bruteforce attacks.
I tried looking for the security margin (time delay between checking each phrase) added by this measure to eff gauge the real security of FDE. Also recent GPU speedups and ways to circumvent the computational cost has changed things. Its probably best to just use the number of words giving 256 protection than trying to guess the efficacy of these anti-bruteforce measures because not all encryption systems necessarily have them.
We should get confirmation from multiple sources about that information? (On how much entropy per X generally?)
It does. From your quote:
And a dictionary contains words like:
is, a, and, of and so forth.
To bring this point to the extreme for illustrative purposes, this would be a 6 words phrase: is-so-of-a-me-no
16 characters only. Only normal letters and dash. Common easy English words only. Quickly broken during bruteforce. That’s why too short words were removed in EFF list otherwise who wouldn’t like having as short words in their password as is-so-of-a-me-no?
Do rainbow tables defeat key stretching enhanced keys?
It requires 1 second to calculate the key stretching enhanced key. Why doesn’t luks (configurable) allow key stretching which taking 1-60 seconds and/or 1-10 minutes or whatever? Maybe it does, that is --iter-time.
I wouldn’t mind increasing the time it takes on each boot to generate the enhanced key from 1 second to 60 seconds. A 60 seconds longer boot times is very welcome is brute forcing my key gets 60 times harder. TODO research
OK that’s a strong argument against rolling our own word list then.
Summary: Rainbow tables stopped being relevant to password hashing systems long ago [0]. scrypt, bcrypt, PBKDF2 recommended by NCC in order of preference [1]. The most cutting edge scheme is Argon2id winner of NIST’s password hashing competition [2]. cryptsetup in Debian Sid supports Argon2 though there are bugs to iron out and I don;t think its set as the default [3].
Could you please add the easy/non-controversial things first?
Like “I recommend a minimum length of 20 characters, including spaces between the letters.” translates into “in any case, the resulting diceware passphrase should not be shorter than 20 characters”. This might matter for 5/6 words length diceware passphrases?
5.13 Is LUKS with default parameters less secure on a slow CPU?
Unfortunately, yes. However the only aspect affected is the protection for low-entropy passphrase or master-key. All other security aspects are independent of CPU speed.
The master key is less critical, as you really have to work at it to give it low entropy. One possibility is to supply the master key yourself. If that key is low-entropy, then you get what you deserve. The other known possibility is to use /dev/urandom for key generation in an entropy-starved situation (e.g. automatic installation on an embedded device without network and other entropy sources).
For the passphrase, don’t use a low-entropy passphrase. If your passphrase is good, then a slow CPU will not matter. If you insist on a low-entropy passphrase on a slow CPU, use something like “–iter-time=10000” or higher and wait a long time on each LUKS unlock and pray that the attacker does not find out in which way exactly your passphrase is low entropy. This also applies to low-entropy passphrases on fast CPUs. Technology can do only so much to compensate for problems in front of the keyboard.
Also note that power-saving modes will make your CPU slower. This will reduce iteration count on LUKS container creation. It will keep unlock times at the expected values though at this CPU speed.
Could you ask him please if very high values for luks -h sha512 --iter-time as per my last post makes sense? How much can --iter-time / PBKDF2 do for us? Could even a 5 words diceware passphrase be stretched long enough if the --iter-time number is high enough? What value should we use for --iter-time? Probably depends on how many diceware words are being used. What would be the minimum number of diceware words / characters so --iter-time / PBKDF2 can stretch to 256 bits?
PBKDF2 is not good for password stretching against GPUs as multiple instances of it can be run in parallel, independent of each other. So you would only be inconveniencing yourself during boot up without tangible security gains if you are not using modern alternatives like Argon2id.
Its more appropiate to ask the LUKS/cryptsetup devs on details about using the latter and what security margin it provides IMO, no?
With no clear answer on what the security margin of keystretching implementations like Argon2id is nor the ubiquity of such mechanisms*, let’s go ahead and recommend a 20 word passphrase length for PQ security.
Yes its hard but there are harder things in the opsec world. I’m sure with enough time it can be done.
*Imagine vetting the source of every piece of crypto software to determine what kind (if any) of keystretching is implementing and giving suitable advice(1) it becomes too complicated and users might make mistakes based on wrong assumptions.