As long as your system doesn’t come back with a load 2 and 3 character words you’d probably be fine.
You are pulling from a smaller character set so you’d need the total length to be greater than 20.
A shade under 1% of the “most basic” 65536 words are length 1, 2 or 3 - so there is an approximately 93% chance that a generated sentence (of 8 words) does not include any word of length 1, 2 or 3. It would be very unlikely that a sentence would contain a load of such short words.
Here are some examples:
inconclusively cuts hooked crusade agent's cola's blent pastries
wayside meats trimester hampers handfuls bungs astonishing functionality
You can make your own contemplation of whether it would be better to exclude words ending in 's (which are mostly possessives but may be contractions).
It would be possible to sacrifice some entropy by manually re-ordering the words before use in order to form a more meaningful sentence, where this is possible.
It is at the discretion of the user whether the spaces between the words are actually typed but for any given use of a pass-sentence consistency is mandatory and across multiple uses consistency is desirable.
1 Like
2,5x or even more characters for same security to type on OSK. I would hate to restart my device. 
On physical keyboard it’s kinda different, since it’s easy to type.
Yep. But the poster was commenting on ease of memorisation.
You are also free to abbreviate any word so long as the abbreviation is unique to that word i.e. less typing, same entropy - providing that you can remember how you abbreviated the word. Or if you are prepared to sacrifice a few bits of entropy here and there, you can abbreviate without worrying about uniqueness.
You can claw back some entropy if you can ensure that the dictionary in plain text does not fall into the hands of the attacker (and there is certainly no need to keep it around, in plain text or otherwise, once you have used it).
For sure. However the original context of this discussion was actually a laptop - and discussion of LUKS applies to any device that runs Linux.
At least you don’t have to change “keyboard” if the password is all lowercase and space. Compare that with entering my WiFi password on a mobile phone where I am jumping from one keyboard to another like a crazy man.
1 Like
True.
As I said before, I remember the movement-pattern of my fingers, so my left thumb changes the layers while my right index finger types in. That works pretty well. I don’t need to know where is which sign, but where to move finger next.
But since we also share methods to create strong passwords … the layers can even help to create such pattern for those who cannot remember “chaos pattern”. On OSK they’re strong, because we use letters and special sign on same buttons. Give a look into this Squeekboard layout (not the same as for LUKS on boot):
You can remember the smiley, change the layers and break the “picture” with one or two other buttons (green-yellowish button). At the end you have a password like Lo8°€#aR: Combine with a 2nd picture (should be together min 19 sign, we know right now 
) and you have a very strong password that can be remembered easily. You can create every possible “picture” that does not even make sense to others. You can “draw” it in the order you want (I did loij-dsa-r-v, but could also v-j-loi-r-asd) to “hide” that you “draw” something. Just don’t use “too easy patterns” like asdfghjkl, even not with different layers.
The good thing about this is also the higher typing speed. It also makes it more hard for 3rd eyes to follow your fingers. Think about this situation: someone sits on bus behind you and you type in your sentence. Even if the person just read hell and see that there was another letter he couldn’t follow, he knows it’s hello. Typing in passwords in the public is danger anyway, but we all know that people will do it.
Although considered improbable, it’s not impossible.
Getting back closer to topic of using/switching to Argon2id here are some not so scientific times for various Argon2id parameters on a standard Librem 5, the times should be considered +/-0.5 seconds and also consider that not all boots are exactly equal. The times are the duration, during boot, between hitting enter on the passphrase screen to being presented with the OS lockscreen.
Default (baseline):
# cryptsetup luksConvertKey /dev/mmcblk0p2
PBKDF: argon2i Time cost: 4 Memory**: 360507 Threads: 4
Duration (Passphrase to lockscreen): ~18 seconds
** Memory from benchmarking can vary, I have seen this value anywhere from ~330M to ~370M
Now might be a good time to point out that if you set non-default parameters you have to pass those parameters to any command/action that operates on the key slots (e.g. luksChangeKey, reencrypt, etc,.) if you do not pass the additional parameters cryptsetup will assert defaults.
1G memory costs…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 \
--pbkdf-memory $((1024*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 4
Duration (Passphrase to lockscreen): ~20 seconds
For the Librem 5, the boot time cost for the same level of passphrase protection as @irvinewade’s benchmarked desktop is ~3 seconds…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 5 \
--pbkdf-memory $((1024*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 5 Memory: 1048576 Threads: 4
Duration (Passphrase to lockscreen): ~21 seconds
1.5G memory costs…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 \
--pbkdf-memory $((3*512*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 4 Memory: 1518702 Threads: 4
Duration (Passphrase to lockscreen): ~22 seconds
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 5 \
--pbkdf-memory $((3*512*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 5 Memory: 1518702 Threads: 4
Duration (Passphrase to lockscreen): ~24 seconds
~1.5G is as much as you’ll get for the memory cost on a standard Librem 5 with 3G RAM. If you want to harden your passphrase protection further you can manipulate the LUKS header off-line from another machine with higher resources…
2G memory costs…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 \
--pbkdf-memory $((2*1024*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 4 Memory: 2097152 Threads: 4
Duration (Passphrase to lockscreen): ~26 seconds
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 5 \
--pbkdf-memory $((2*1024*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 5 Memory: 2097152 Threads: 4
Duration (Passphrase to lockscreen): ~28 seconds
2.25G memory costs…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 \
--pbkdf-memory $((9*256*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 4 Memory: 2359296 Threads: 4
Duration (Passphrase to lockscreen): ~26.5 seconds
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 5 \
--pbkdf-memory $((9*256*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 5 Memory: 2359296 Threads: 4
Duration (Passphrase to lockscreen): ~29 seconds
2.25G is about as high as you can go while still being able to operate on the key slot area, at 2.5G, the phone will boot fine but any attempts to operate on the key slots while the system is live/running will most likely fail due to running out of memory verifying the key slot passphrase.
2.5G memory costs…
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 4 \
--pbkdf-memory $((5*512*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 4 Memory: 2621440 Threads: 4
Duration (Passphrase to lockscreen): ~27.5 seconds
# cryptsetup luksConvertKey --pbkdf argon2id --pbkdf-force-iterations 5 \
--pbkdf-memory $((5*512*1024)) --pbkdf-parallel 4 /dev/mmcblk0p2
PBKDF: argon2id Time cost: 5 Memory: 2621440 Threads: 4
Duration (Passphrase to lockscreen): ~30 seconds
2 Likes
The risk is that a change to the kernel (or config) to use slightly more memory in the early boot could push you over the limit and it may stop booting after that upgrade, which would be painful to resolve (particularly if you are “out and about” at the time1) and some customers would be stumped. So I think I would be inclined to take the implied maximum of “half the memory”. Even half the memory is making the point to the would-be attacker that “they’re gonna need a bigger GPU”.
1 For that reason I tend to refuse all updates on portable devices until such time as I am at home with the device.
2 Likes
I remember years ago a friend of a friend who happened to be a Computer Forensic dude mentioned something about keyboard wear patterns enhanced with digital photography that would put their focus on those keys only and their success rate was in the high 90 percent in opening an encrypted drive. IDK…just thought it was interesting to share.
3 Likes
Sounds like that could be countered by at least two ideas:
- Using a password that uses the entire keyboard for an even distribution.
- Replacing the keyboard entirely.
Or a silicone keyboard protector?
1 Like
Well I would assume someone who can measure wear on keyboard keycaps can also measure wear on keyboard silicone protectors.
Yeh, unless they were referring to finger print acidic deposits…IDK never sought sought an elaboration on it. Or you could just dispose of the protector and use a new one…
1 Like
There is also a significant assumption in that the wear of the keycaps directly correlate to the password, but keyboards are used for far more purposes then just that, like typing documents or news articles. Such forensic techniques cannot determine between these activities based on wear alone.
1 Like
That is true. But I would imagine the frequency of keys used as compared to other keys they would be able to eliminate other keys to a certain subset that would increase their chances of a brute attack …again all gotten I guess by acidic deposits and directional pushes of those deposits to gain letter associations with those keys?
1 Like
We need sources for these physical forensic techniques. I was unable to find any relevant information regarding them using various keywords from this discussion.
2 Likes
Yeh…pretty much assuming. Like I said in my original post that was coming from a friend of a friend in passing conversation years ago, which i used for my own security needs…like using keypad covers. and a very long password which is memorized upper lower case letters, numbers along with special characters and spaces.
Edit. A cursory search did pop up something else which is interesting…its a technological leap from what I described from years ago but interesting none the less
1 Like
That was my first thought too. And in fact, my keyboard for desktop is so old and heavy used, that I can see with my eyes easily(!) what keys are often used. But I can tell that it is definitely no indicator of my passwords.
That’s an attack for people who don’t use often a pc … maybe 90% of time for login into e-mail account to read them. They type passwords more often than anything else, but they are also uninteresting to hack them via this way (remember you need access to physical keyboard).
And people who’re interesting to get access are usually heavy pc users and do a lot of stuff with it. The usage of keys are higher on other activities. I think it’s more a laboratory method than something for real attacks.
I guess same with the heat-method. Someone needs local access and watch the heat via camera. But if you want to do it this way, you also could install a real camera or a keylogger.
2 Likes
Yeh, As i mentioned prior, this was said by a Computer Forensic dude years ago and I would imagine that it is under laboratory conditions like you mentioned. I am not sure what kind of equipment would be used for that.
As far.as the thermal goes maybe a small password can be had with this method…I used my Flir to test keyboard capture on my L13 and captured about 5 strokes and the rest dissipated before photographic capture…
Interesting thread however.
2 Likes
You may need a camera that can capture on 10th or even more parts of a degree to get more keys. I don’t know what’s the accuracy of a common heat cam, but it seems to be not good enough to get close to 16 keys. However, if you have a 8-sign password and 5 are captured, you can brute force the rest easily.
Yep, definitely interesting thread.
2 Likes
Or, in the specific case of a device like the Librem 5 with an on-screen keyboard, you can randomize the keyboard for the purposes of LUKS password entry. This counters or at least frustrates a number of techniques that might be able to recover the password. On the downside, it will force you to enter your LUKS password more slowly.
3 Likes