On 10 Dec 2019 10:42 -0700, from lists@xxxxxxxxxxxxxxxxx (Chris Murphy): > A possible better workaround for this problem, is helping the user > create a recovery passphrase, and maybe even some desktop environments > or installers go with a policy where the user is taken through this by > default. That'd be a randomly generated passphrase, limited character > set (perhaps ASCII), so that it's unambiguous. There is a bias, > predicating it on Latin input. But it's better than data loss! And > then display that recovery passphrase for the user to escrow somewhere > safe. And then almost any keymapping or keyboard still gets the > encoding for this passphrase correct. > > If an attacker sees more than one keyslot used, and assumes one is a > recovery key, and assumes the passphrase is ASCII, haven't they > improved their bruteforce attack capability? And that comes full > circle back to whether the keymapping and keyboard locale information > should be stored somewhere, and checked at passphrase entry time, and > the user warned if there's a mismatch. As you say, it's not _just_ an encoding problem. There's character encoding, particularly but not exclusively for non-US-English characters (0-9, A-Z, some punctuation). (This is the mapping from glyphs on the screen to bits and bytes in memory.) There's keyboard layout. (This is the mapping from physical key to glyphs on the screen.) Particularly on laptops, there's also the issue that some have an integrated numeric keypad _overlaid on the alphanumeric portion of the keyboard_, which can definitely trip you up. If you're unlucky, there's a flaky key switch which causes a key stroke to not register properly. And probably one or two things I'm forgetting at the moment. For a recovery passphrase in particular, I'd suggest going with the restricted character set that Yubikeys use (termed "modhex"), as that is specifically selected to work across as wide a range of keyboard layouts as possible. Wikipedia gives that character set as [cbdefghijklnrtuv] (16 characters, mapping to hexadecimal digits). Brute force attacks on the passphrases are only feasible if the passphrase is short and/or otherwise poorly selected. A recovery passphrase can be long, random, and use a very high iteration count if so desired; you get a 2^256 work factor (given what we know today, more than enough for anyone who doesn't plan to outlast the heat death of the universe) with just 64 modhex characters, even if the attacker knows how the passphrase was generated, as long as it's properly _random_. That's _plenty_ short enough to write down by hand on a piece of paper. If you're paranoid, add to that a few seconds' worth of iteration count, and attacking that passphrase is in no way easier, and quite likely harder, than attacking the master key directly. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “Remember when, on the Internet, nobody cared that you were a dog?” _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt