Imagine your hard drive encrypted with 7-8 word diceware password. And then stolen. Does it feel safe enough?
Or someone uploading a backup of all their data uploaded to cloud storage.
In these cases, do we trust 7-8 word diceware password will still have safe >= year 2050?
What about the IAD-NSA / NIST recommendation? I misinterpret it or we just discard it?
256 bits = 20 word diceware passphrase. Seems excessive right? Example:
There are 20 words in your password, resulting in ~258.50 bits of entropy (~12.92 bits/word, ~10 bits/letter, and ~5.16 bits/symbol). That many words equates to a total keyspace of ~653,318,623,500,070,900,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible phrases (7776^WordsInPhrase). An adversary might get lucky and guess your phrase on the first try, though the chances of that happening are very slim. On the other hand, the brute-force attacker might be forced to try all of the keys in the keyspace to finally find that the last guess was the correct one. On average, it takes trying 50% of all phrases in the keyspace to find your phrase. The time it takes to discover your passphrase is based on how many guesses per second your attacker can muster. At the lower end in 2016 a small cluster of GPU’s have demonstrated the ability to crack ~350 billion hashes/second. A nation state actor like the NSA may be able to perform quadrillions/second. Conservatively assuming a professional adversary can guess passwords at the rate of a 1,000,000,000,000 keys/second (Edward Snowden suggests being prepared for a Trillion guesses per second), an exhaustive brute-force search on 50% of the total keyspace might take:
~326,659,311,750,035,450,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 seconds
~5,444,321,862,500,590,833,333,333,333,333,333,333,333,333,333,333,333,333,333,333,333 minutes
~90,738,697,708,343,180,555,555,555,555,555,555,555,555,555,555,555,555,555,555,556 hours
~3,780,779,071,180,965,856,481,481,481,481,481,481,481,481,481,481,481,481,481,481 days
~10,358,298,825,153,331,113,647,894,469,812,278,031,456,113,647,894,469,812,278 years
~154,141,351,564,781,713,000,712,715,324,587,470,706,192,167,379,381,991,254 x avg. lifespan
~10,358,298,825,153,331,113,647,894,469,812,278,031,456,113,647,894,469,812 millenia
~750,710,162,715,852,378,145,230,792,130,183,941,981,164,925,924 x age Universe
I may be misunderstanding but cipher keylength =/= password entropy? Quantum computers do not have implications for password bruteforcing but for master key brute search?
Now if it turns out I’m wrong the question becomes: how can a 10 word passphrase be easily enhanced to get as high entropy as possible without having to double its size?
Its best to go by public NIST guidelines and then some, since these guys have some of the best cryp analytic capability but that doesn’t mean we should blindly follow everything they say and so we compare with what the public crypto community has to say.
There is an option for diceware to sprinkle random characters in its output but I don’t know how much entropy bits it adds. Do you know?
Already did on the password page so 2FA one is redundant?
+1 but since its not implemented anywhere there’s no need to mention it
using EFF’s [https://www.rempe.us/diceware/#eff online tool]
No indication this tool is by EFF. Removed.
That is only SMS based 2FA. I haven’t seen comments on HTOP / TTOP based 2FA (google authenticator / AndOPT / …) nor hardware device based (such as yubikey https://www.whonix.org/wiki/Dev/yubikey) nor https://en.wikipedia.org/wiki/WYSIWYS. 2FA is a too broad term to discard it entirely.
I am not sure that’s possible without compromises. I am not sure it’s fair to paraphrase but if that would be possible why wouldn’t the following be possible.
Reinhold in chapter How long should my passphrase be? links to http://www.keylength.com but perhaps I am misunderstanding him referencing it there.
I saw an online diceware password generator that pointed out how much entropy random characters or random letters written case insensitive would give.
sim-cloning and then conducting social engineering attacks on the cellular provider
I guess that is sim-cloning or conducting social engineering attacks on the cellular provider. Because one capable to clone a sim doesn’t need to trick the celluar provider into porting the number.
Reply from JP Aumasson about password entropy quoted here verbatim until it appears on whonix-devel:
Hi!
You want the passphrase to have at least as much entropy as the bit length
of the symmetric key that is derived from it.In theory, Grover’s quantum search algorithm could lower down the cost of
searching the right passphrase from ~2^128 to (very) roughly ~2^64.How to get higher entropy passphrase? You can have a longer passphrase, a
longer dictionary (that is, more entropy per word), or both.BIP 39 for example supports 128 to 256 bits of entropy per passphrase, iirc
with 2048-word lists, thus longer passphrase for higher entropy, see
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawikiHope this clarifies!
Best,
JP
Fair enough. I wasn’t familiar with these other options that counted as 2FA too.
Seems legit if all components client/server are libre.
https://blogs.forgerock.org/petermajor/2014/02/one-time-passwords-hotp-and-totp/
AndOTP is interesting. Something like OpenAM which is a server side HOTP implementation can be used with an open client like AndOTP, KeePassXC.
https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm#Server_implementations
Overall a good idea if you are not communicating with a surveilling PRISM server and you’re signing on to an onion.
Does Yubikey security depend on its hardware security? Was its hrdware ever open? It seems its software was at some point but that changed with time.
Code was discovered broken by black box testing. I don’t think YubiKey should be recommended anymore.
WYSIWYS sounds nice. Do you know any implementations of it?
What does this mean in practice?
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)
A or B is right?
https://packages.debian.org/stretch/wamerican-insane
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. https://forums.hak5.org/topic/29308-13gb-44gb-compressed-wpa-wpa2-word-list-982963904-words/
Does if have the prefix code problem? See https://github.com/ulif/diceware/#id3 under security traps.
No because diceware auto-capitalizes each word.
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?
https://packages.debian.org/stretch/wamerican-insane 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.
Apparently the answer is ~5 bits for symbols - source: https://www.rempe.us/diceware/#eff
There are words in your password, resulting in ~ bits of entropy (~12.92 bits/word, ~10 bits/letter, and ~5.16 bits/symbol).
See his: https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases
Word length doesn’t impact security:
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.
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption#What_choice_of_hash_for_key_derivation.3F
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].
[2] https://en.wikipedia.org/wiki/Argon2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890798