Passwords
From Whonix
About this Passwords Page  

Support Status  stable 
Difficulty  easy 
Contributor  HulaHoop ^{[archive]} 
Support  Support 
Introduction[edit]
Warning: In 2013, nationstate adversaries were supposedly capable of one trillion guesses per second when attempting to bruteforce passwords. ^{[1]} Considering Moore's Law it could have only improved since.^{[2]}
If weak passwords (passphrases) are used, they will be easily discovered by trying every possible character combination in reasonable time through bruteforce attacks ^{[archive]}. This method is very fast for short and/or nonrandom passwords.
This chapter discusses:
 How to calculate entropy for both prequantum and postquantum strength;
 Estimating the brute force time for passwords of different length;
 Keystretching measures which help to make password length manageable in a postquantum world; and
 Principles for stronger passwords.
Generating Unbreakable Passwords[edit]
Introduction[edit]
To generate strong passwords that are both easy to remember and have an easily calculatable large entropy, it is advised to use the Diceware package. Instead of generating a random sequence containing alphanumerical and special characters, Diceware selects a sequence of words equiprobably from a list containing several thousand that have been curated for their memorability, length and profanity.
Passwords that are long enough should be safe for millions or billions of years, even if the list chosen is known to the attacker. This relies on the fact that the time taken to try all possible combinations would be infeasibly large, even for a wellequipped adversary. ^{[3]} ^{[4]}
Diceware Password Strength[edit]
When determining appropriate password length, ideally it should have at least as much entropy as the bit length of the symmetric key that is derived from it. ^{[5]} As will be explained later, one can deviate from this rule to have a shorter password while still having a realistically strong protection level. The entropy type referred to throughout this page is Shannon Entropy. The concept of Minentropy^{[6]} measures the worst case lower bound of passphrase entropy in case of diceware generating words that have semantic meaning as a sentence or short passphrases whose character length can be easily bruteforced. This in practice is extremely unlikely and is detectable by the user and in the latter case a recommended number of words is advised to mitigate this risk.^{[7]}
Entropy ^{[archive]} per word is calculated by dividing log of number of words in list by log 2. List lengths vary.
EFF list:
log (7776) / log (2) = 12.92 bits
SecureDrop list:
log (6800) / log (2) = 12.73 bits
Total password entropy is:
number of words * entropy per word
There are 32 special characters on a standard U.S. keyboard:
log (32) / log (2) = 5 bits per character
Alternatively, an alphanumeric string using lower/uppercase will have 62 characters in the set:
log (62) / log (2) = 5.95 bits per character
The relationship between entropy and the length of the diceware password is outlined below.
Table: Diceware Password Strength ^{[8]}
Word Total  Bits of Entropy  Estimated Bruteforce Time (Classical Computing) ^{[9]}  Futureproof Safety ^{[10]}  Postquantum Secure ^{[11]} 

Five  ~64  ~165 days  No  No 
Six  ~78  ~3,505 years  Maybe  No 
Seven  ~90  ~27,256 millennia  Yes  No 
Eight  ~103  ~15 x age Universe  Yes  No 
Nine  ~116  ~119,441 x age Universe  Yes  No 
Ten  ~129  ~928,773,415 x age Universe  Yes  No 
Fifteen  ~194  ~26,405,295,715,806,668,059,525,829,264 x age Universe  Yes  Yes 
Twenty  ~259  ~750,710,162,715,852,378,145,230,792,130,183,941,981,164,925,924 x age Universe  Yes  Yes 
Calculating Bruteforce Time[edit]
Moore's Law ^{[archive]} predicts the doubling of number of ondie transistors every 24 months (two years). Other estimates by the industry put that at 18 months. It is expected that Moore's Law ends by 2025 because of physical constraints of silicon.
1 trillion guesses in 2013 = 2^{40} operations.
Lower bound  Doubling every 24 months 20132025:
2^{46}
Upper bound  Every 18 months 20132025:
2^{48}
To gauge strength against adversary capabilities, an example 80bit password versus an adversary capable of 1 trillion or (2^{40} guesses per second):
2^{(8040)} = 2^{40} seconds
Which is then divided by 31536000 seconds / year to get the number of years. ^{[12]} ^{[13]}
Classical vs Quantum Computing[edit]
Classical Computing Attack[edit]
 7word diceware passphrases are recommended, yielding ~90 bits of entropy against classical computing attacks. ^{[14]}
 10word diceware passphrases provide 128 bits of entropy.
Quantum Computing Attack[edit]
 Grover’s quantum search algorithm halves the key search space, so all entropy values in the table above are halved on quantum computers. For example, the cost of searching for the right 2^{128} passphrase drops to (very) roughly ~2^{64}. ^{[15]}
 A 20word passphrase with 2^{256} bit entropy today, yields 128bit postquantum protection.
 Quantum computers do not impact the entropy provided by keystretching algorithms. See below. ^{[16]}
KeyStretching[edit]
Depending on how it is implemented, keystretching introduces a major speedbump for bruteforcing as it forces an adversary to undergo extra steps compared to processing vanilla, symmetric, master encryption keys. They allow passwords to be shorter while adding a certain entropy security margin. Note this does not help if bad passwords are chosen.
Passwords for LUKS FDE are secured using a keystretching implementation known as a PasswordBased Key Derivation Function (PBKDF). The older HMACSHA* algorithm is less effective against parallelization by GPUs and ASICs  the same weaknesses suffered by Bitcoin against dedicated mining hardware.
Argon2id is the winner of the Password Hashing Competition ^{[archive]} and the stateoftheart hashing algorithm of choice when protecting encryption keys. Its memoryhard properties introduce a large penalty for brutesearch on general computers and even more so on GPUs and ASICs.
Choosing Parameters[edit]
This is how to calculate entropy for Argon2id. An example ^{[17]} using arbitrary parameters is below:
 1 GiB RAM, 50 iterations and 4 threads
 m=1GiB, t=50, p=4
The "20" comes from the exponent of 2 that gives the number of kibibytes that is used in 1 GiB RAM (2^{20} = 1,048,576 kibibytes in this case). The number of 1 KiB block operations is most important. For 4 GiB, the exponent becomes "22" (2^{22} = 4,194,304 kibibytes).
General Computers "Lower Bound"
20 + (log (50) / log(2)) = ~26 bits
GPUs and ASICs "Upper Bound"
20 + (20  (log (8*4) / log (2))) + (log (50) / log (2)) = ~41 bits
Subtracting the parallelism (8x within a block and 4x threadlevel p=4), because for this sort of attack the parallelism reduces the duration for which the memory has to be occupied.
Comments ^{[17]}
Then, I think t=50 is excessive. It isn't even the equivalent of a one word longer passphrase, but it takes more time than typing a word would. Perhaps you should consider t=3. That will be only "4 bits" less, giving you something like 22 to 40 bits (depending on attack hardware) of stretching relative to BLAKE2b. SolarDesigner (OpenWall lead and cryptographer who participated in the Password Hashing Competition)
Migrating LUKS FDE to Argon2id[edit]
These steps migrate systems which are currently encrypted with LUKS first from a LUKS1 to LUKS2 header, then shift to Argon2id. Removable media migration should be straightforward, however the main running system will require extra preboot steps because an open encrypted volume cannot be modified. ^{[18]} Take precautions such as backing up your data and make a copy of the required steps since they will be inaccessible during part of the process.
1. Enumerate all devices to determine partition name.
# ls /dev/
2. Verify the partition in question is an encrypted one (typically sda5
on default, noncustomized installs).
# blkid p /dev/sda5
3. Inspect LUKS header details and confirm it was converted in the end.
# cryptsetup luksDump debug /dev/sda5
4. Check kernel module availability.
Before rebooting, it is advisable to check the ‘algif_skcipher’ kernel module is included in the initramfs image, otherwise it might not be possible to open LUKS2 volumes. ^{[19]} To do so, run the following two commands:
# echo algif_skcipher  sudo tee a /etc/initramfstools/modules sudo updateinitramfs u
5. Reboot and convert the header.
Now assuming the bootloader is GRUB:
 Reboot.
 Press <E> to obtain an emacslike screen.
 Append “ break=premount” to the line starting with “linux”.
 Press
Ctrl
+X
to boot  the edit is transient and will not survive the next reboot (users should land into an initramfs debug shell).
Convert the header to LUKS2:
cryptsetup convert /dev/sda5 type luks2 debug
Then convert to Argon2id. Parameters used in this example:
 1 GiB RAM.
 50 iterations.
 4 threads.
cryptsetup luksConvertKey keyslot 0 pbkdf argon2id pbkdfforceiterations 50 pbkdfmemory 1048576 pbkdfparallel 4 /dev/sda5
Guidelines[edit]
Argon2id Entropy Estimates[edit]
For LUKS FDE where memorization is a burden (assuming EFF list and 26 bit Argon2id lower bound):
 [postquantum] 10 words + Argon2id = ~90 bits
 [postquantum] 11 words + Argon2id = ~97 bits
 [postquantum] 12 words + Argon2id = ~103 bits
For LUKS FDE where memorization is a burden (assuming EFF list and 24 bit Argon2id lower bound for faster logins [configured by 4 GiB, 3 iterations, 4 threads]):
 [postquantum] 10 words + Argon2id = ~88 bits
 [postquantum] 11 words + Argon2id = ~95 bits
 [postquantum] 12 words + Argon2id = ~102 bits
In summary, 12 words is the safest compromise, giving a comfortable security margin at mild cognitive expense.
For any other encrypted media/container that does not implement Argon2id or where memory is not a problem because you can safely store the password on your encrypted computer:
 [postquantum] 20 words = 128 bits
Alternatively if memorization is not a problem in the case of nonsystem media, a shorter alphanumeric string consisting of 43 characters will achieve 128bit postquantum strength: ^{[20]} ^{[21]}
head /dev/random  tr dc AZaz09  head c 43 ; echo ''
For usability makepasswd
can be used instead. Its reliance on /dev/urandom ^{[22]} is no cause for concern: ^{[23]} ^{[24]} ^{[25]} ^{[26]}
makepasswd chars 43
Password Generation[edit]
For all practical purposes the Linux RNG is sufficient for selecting words in a random fashion. To go one step further, dice can be used to physically choose the diceware words. ^{[27]} ^{[28]} ^{[29]}
The "diceware" package ^{[archive]} is available in Debian. To generate a 12word password from the EFF's list, run:
diceware n 12 w en_eff
Follow this additional advice for Diceware passwords: ^{[27]}
 Diceware passwords should have spaces between each word, otherwise the strength of the password is materially weakened. For example, a sixword passphrase without spaces “stray clam my aloof micro judo” has the same strength as a fiveword passphrase “stray clammy aloof micro judo” with spaces.
 Only change passwords if a compromise is suspected.
 Random character capitalization is not recommended. Although it adds 1 bit per character, it requires regular pressing of the shift key  slowing down typing and increasing the number of keystrokes. Instead, it is better to just make the password longer if additional entropy is required.
Principles for Stronger Passwords[edit]
The human mind is notoriously bad at coming up with truly random passwords: ^{[30]} ^{[31]}
The last time I sat down to work out the statistics from known password lists the initial letter of a password/phrase had less than 4bits of entropy which rapidly dropped to less than 1.5bits by the seventh character, and dropping to a little over 1bit after ten characters. ... The simple fact is computers are now faster and more adept at password cracking than humans can think up memorable ways to remember strings of information that to humans look random..." Clive Robinson
Users should read Wikipedia: Weak Passwords ^{[archive]} to learn about better practices for generating strong passwords and to determine if current passwords are weak. (w ^{[archive]}). The general principles for stronger passwords are outlined below. ^{[32]}
Table: Stronger Password Principles
Domain  Recommendation 

Content and Length 

Poor Habits 

Storage 

Forum Discussion[edit]
https://forums.whonix.org/t/passwordadvicewikipageenhancements ^{[archive]}
See Also[edit]
Footnotes[edit]
 ↑ https://theintercept.com/2015/03/26/passphrasescanmemorizeattackerscantguess/ ^{[archive]}
 ↑ https://www.passworddepot.com/knowhow/bruteforceattacks.htm ^{[archive]}
 ↑ https://en.wikipedia.org/wiki/Diceware ^{[archive]}
 ↑ https://en.wikipedia.org/wiki/Password_strength#Random_passwords ^{[archive]}
 ↑ https://www.whonix.org/pipermail/whonixdevel/2018August/001184.html ^{[archive]}
 ↑ https://crypto.stackexchange.com/questions/66097/whyisminentropysignificantincryptography ^{[archive]}
 ↑ https://www.whonix.org/pipermail/whonixdevel/2019December/001487.html ^{[archive]}
 ↑ https://www.rempe.us/diceware/#eff ^{[archive]}
 ↑ One trillion guesses per second.
 ↑ Safe until at least the year 2050.
 ↑ Assuming Grover's algorithm ^{[archive]} halves the number of iterations required to bruteforce a key. This means doubling the length of symmetric keys to protect against future (hypothetical) quantum attacks.
 ↑ https://security.stackexchange.com/questions/69374/isan80bitpasswordgoodenoughforallpracticalpurposes/69378 ^{[archive]}
 ↑ https://security.stackexchange.com/a/115397 ^{[archive]}
 ↑ https://theintercept.com/2015/03/26/passphrasescanmemorizeattackerscantguess/ ^{[archive]}
 ↑ https://www.whonix.org/pipermail/whonixdevel/2018August/001184.html ^{[archive]}
 ↑ https://www.whonix.org/pipermail/whonixdevel/2018August/001215.html ^{[archive]}
 ↑ ^{17.0} ^{17.1} https://www.whonix.org/pipermail/whonixdevel/2018September/001255.html ^{[archive]}
 ↑ https://www.saout.de/pipermail/dmcrypt/2018September/005974.html ^{[archive]}
 ↑ See: https://bugs.debian.org/896968 ^{[archive]} for details.
 ↑ https://pthree.org/2011/03/07/strongpasswordsneedentropy/ ^{[archive]}
 ↑ https://unix.stackexchange.com/questions/230673/howtogeneratearandomstring ^{[archive]}
 ↑ https://packages.debian.org/stable/makepasswd ^{[archive]}
 ↑ https://pthree.org/2014/07/21/thelinuxrandomnumbergenerator/ ^{[archive]}
 ↑ https://www.mailarchive.com/cryptography@randombit.net/msg04763.html ^{[archive]}
 ↑ https://security.stackexchange.com/questions/3936/isarandfromdevurandomsecureforaloginkey/3939#3939 ^{[archive]}
 ↑ https://stackoverflow.com/questions/5635277/isdevrandomconsideredtrulyrandom/5639631#5639631 ^{[archive]}
 ↑ ^{27.0} ^{27.1} http://world.std.com/~reinhold/dicewarefaq.html ^{[archive]}
 ↑ The reason is the outcome of a dice roll ^{[archive]} is influenced by the physics of gravity, air resistance, torque applied, surface friction, the initial position of the die and other factors. Highfriction surfaces are recommended, since dice tend to bounce more times in a chaotic fashion.
 ↑ Also see: EFF DiceGenerated Passphrases ^{[archive]} and EFF's Long Wordlist (.txt) ^{[archive]}.
 ↑ https://www.schneier.com/blog/archives/2017/05/nsa_bruteforce.html#c6753142 ^{[archive]}
 ↑ https://security.stackexchange.com/questions/6095/xkcd936shortcomplexpasswordorlongdictionarypassphrase ^{[archive]} Second reply.
 ↑ https://en.wikipedia.org/wiki/Password_strength#Guidelines_for_strong_passwords ^{[archive]}
 ↑ https://www.passworddepot.com/knowhow/bruteforceattacks.htm ^{[archive]}
 ↑ https://theintercept.com/2015/03/26/passphrasescanmemorizeattackerscantguess/ ^{[archive]}
 ↑ https://www.wired.com/2016/06/heystopusingtextstwofactorauthentication/ ^{[archive]}
Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.
100px  
Fosshost  About Advertisements 
Search engines: YaCy  Qwant  ecosia  MetaGer  peekier  Whonix ™ Wiki
Love Whonix ™ and want to help spread the word? You can start by telling your friends or posting news about Whonix ™ on your website, blog or social media.
Priority Support  Investors  Professional Support
Whonix ™  © ENCRYPTED SUPPORT LP  Freedom Software / Open Source (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.