Care to offer some examples of threat models where these defaults are considered good, and where they may be considered not so good or insufficient?
That as may be but I don’t believe it any reason to be lax on security on areas outside of social engineering.
Personally, I would expect a device that is marketed by the manufacturer as having a focus on security and privacy, when running an OS from that same manufacturer, to have higher/better/stronger security than the average. When it comes to disk encryption on the Librem5 running PureOS, I feel, out of the box, it could and should be better.
Sure, my threat model is a great example: my Librem 5 is only provisioned for my public identity so its security requirements are more relaxed compared to my Librem 14, which currently manages both a subset of my public identity as well as my private identity. I explain this configuration in more detail on the Qubes OS Forum.
Indeed, as mentioned earlier in the thread, cryptsetup benchmarks the hardware and adjusts the parameters/values based on the results. The result, as you noted is that lesser hardware ends up with lesser passphrase protection/security.
You can make it much longer sure, but you don’t have to go insane. Take the Librem 5 as an example, by default the memory costs comes out at ~370M, you can set the pbkdf to Argon2id with a memory cost of 1G and it’ll add ~2 seconds to boot time, I would think that most people would accept an extra few seconds tradeoff for an increase in passphrase protection. I would suspect that many people probably would not notice. You could additionally up the time cost to 5 (matching your desktop’s numbers) which would extend the boot time by ~2.5 seconds over defaults, an extra ~2.5 seconds to get the same level of protection for your passphrase as your desktop offers doesn’t sound like a bad deal to me and not something I would class as much longer.
cryptsetup allows to specifying the minimum memory costs at 4G maximum, I’m not entirely sure as I have not dug into the code but it seems there may be some logic in there that sets the maximum as the lesser of 4G or half available RAM as it doesn’t matter what value you specify on the Librem 5, anything over ~1.5G gets ignored and minimum memory cost gets set at ~1.5G.
There are some hoops you can jump through to set higher minimum memory costs but they also come with caveats.
Yes, all aspects should be considered, but also no aspect should be overlooked or not taken into account just because it’s only a small part.
From the Argon family, cryptsetup on PureOS Byzantium supports argon2i and argon2id.
Doesn’t entirely surprise me. I didn’t actually check whether it would accept 8GB, only that that would be a perfectly viable amount of memory to devote to a memory-intensive pbkdf. It was more the theoretical point that it must be limited by what memory is available and my phone is unavoidably therefore more limited than my desktop.
(There must be more to it still though because, on my desktop, the lesser of 4 GB and half the memory comes to a lot more than what cryptsetup actually chose for me, as shown above i.e. 1 GB.)
I was referring to the scenario when you specify the parameters rather than relying on defaults/benchmarking, cryptsetup benchmark will set at most a minimum memory cost of 1G.
You ran a straight forward cryptsetup luksFormat with no parameters (i.e. accepting the defaults) so your memory costs will not be any greater than 1G.
Isn’t it more a theoretical discussion over a real security point? I have no problems that you discuss this (in fact, it’s interesting). I just want to have a clear statement of what level this discussion is going on. A lot of posts sounds like encryption on L5 is nearly as weak as no encryption.
Or maybe another question:
What do you think how much sign should we use minimum on L5 on current encryption technology to be brute force safe against strongest attackers - also for the next couple of years?
You may choose still to have one valid passphrase slot but then you have the option of making that quite slow to unlock (much more than you would tolerate in routine use), to be used only in the event that the OpenPGP card is unavailable.
Putting aside the OpenPGP card, @Loki’s post above covers it:
don’t use the cryptsetup default for the hardware (weaker than it needs to be)
use argon2id rather than the other alternatives or failing that argon2d (NB: this is my comment)
push the memory requirement towards 1.5 GB
push the time cost up to what you will tolerate
keep the remaining default parameters (LUKS2, 512 bit master key, 4 threads)
I was not clear enough - I was speaking about the default encrypt settings. Our password length can be 512 sign I read. What’s the minimum length we should have? I read your posts, so I already got this. But also those settings does not help, if I’m using a 4 sign password.
My general recommendation is for a passphrase that’s protecting a master key of a / (root) drive/filesystem, that passphrase should be of at least 128bit entropy, I’d consider that “good enough” for the average user.
I also recommend that if you don’t have to physically type the passphrase, use a radmonly generated key file which is itself PGP encrypted and can be decrypted via OpenPGP smartcard as @irvinewade touched upon. Of course some consideration has to be given to the security of the PGP master keys (and round we go again!!)
Correct, as touched upon previously in the thread…
If I had to chose between a high entropy passphrase with no/low key derivation function or a strong key derivation function with a low entropy passphrase I would chose the high entropy passphrase all day long. But, you don’t need to chose, you can make use of both and these are only small pieces of the puzzle.
Digressing a little but still tying in with a lot of the discussion that has already occurred, one scenario where you don’t (often) have to physically type the passphrase is WiFi.
With WiFi (WPA Personal, and WPA2 Personal), the more vulnerable PBKDF2 can only be used (because by definition independent systems have to arrive at the same final master key, given the same passphrase and SSID, you don’t get an easy choice of the key derivation parameters) and a low number of iterations can only be used (for the same reason but also because WiFi client devices might be quite underpowered - the number of iterations is 4096).
In that scenario, I would recommend around 200 bits of entropy in the passphrase i.e. pushing up towards the limit of the final master key (256 bits). (There is no point using a passphrase with more than 256 bits of entropy, although the specification allows it.)
Some systems will allow you to configure the 256 bit master key directly, bypassing the passphrase - but that is a grueling and error-prone 64 hex characters.
128=log2(107^19)
I know, non ASCII characters are not supported, but they also work. I don’t see any reason not to use them since they can be used via OSK.
If you limit yourself to printable ASCII (95 code points) then you need 20 characters.
If you use anything that has 107 code points (whatever the set of code points might be) then you can get away with 19 code points.
(The program that I use for true random password generation doesn’t offer anything with 107 code points, hence I’m always going to be reporting entropy for more mainstream choices.)
Technically if the attacker can’t guess what the code point set is then that is additional entropy. The OSK configuration and other relevant configuration is unavoidably available in plaintext but there’s probably still an opportunity to scrounge an extra bit or two e.g. if multiple keyboards are available.
If you want to think of it like that then, sure, go ahead, you’d be incorrect, but your free to do so nonetheless.
There is no direct correlation between entropy and length (or character count) of a passphrase. Specifics regarding input methods (and possibly specifics layouts of those input methods) should not be considered general recommendations.
I chose to answer in terms of entropy mainly for clarity, but also as I would prefer to avoid discussions about what is or how to construct a good/strong passphrase.
But, taking you suggestion of 19 sign length with on screen keyboard on L5 I came up with 1234567890987654321 as my passphrase, 19 characters in length and can be input via the onscreen keyboard of the Librem 5, so job done, I’m now super secured!!
These recommendations or advice/comments need to be preceeded with "genuinely random" (19 characters from the OSK of the Librem 5 | 20 printable ASCII characters) doesn’t necessarily provide 128bit entropy.
I can only speak for myself on this, these types of passphrases present me with some problems. There is no way I am able to commit this type of passphrase to memory on first sight, it takes me using the passphrase with some regularity over an amount time before it’s in memory, I have to have it securely recorded until such times as it’s committed.
Sat at home or in an office, it’s no real problem to have a secure record of a passphrase on hand. For mobile devices, phones, laptops etc,. keeping the passphrase secure while also having it accessable for recall is a little more tricky, I’m not sure how I would acheive it.
For most of my LUKS containers, I don’t what the passphrase is, I use something along the lines of…
For / (root) drives/containers unlocked at boot I use key scripts with OpenPGP smatcards, and for containers that I work with via command line, I typically read it in as a key file from a fifo in another session…
# cryptsetup open --key-file /path/to/passkey .....
That was the answer of the question I asked. Nothing about bits and other stuff that most people don’t understand.
Of course you should use all OSK layers to make fully use of characters, then it’s around 128bit (one more, one less). A password with 19 times the same sign is weak of course. Oh now I read your last sentence of this post - you really thought like this. So yeah, make use of the full range and 19 are enough to reach 128bit.
At least I also just asked for a “minimum” - you also can use 45 numbers, if it makes you more happy.
That’s why I remember it in motion. I know which movement my fingers have to go instead of remember the characters. Ask me about my password and I can’t tell you. But I unlock it every time again. And of course it’s not such a simple motion like 1q2w3e4r5t etc. At least for me it’s much easier to remember complicated movement pattern than complicated passwords.
Some people prefer to use random sentence passphrases. For example, if you have a dictionary containing 65536 words (in the language of your choice) and you use a program to generate 8 independent random numbers uniformly from the range 0…65535, then use each number as an index into your dictionary … thereby producing an 8 word sentence (whose total length is not readily predictable but will clearly exceed 20 by a significant margin) … then you have 128 bits of entropy, but should be easier to remember than 20 (true random) printable ASCII characters.
