On Tue, Dec 10, 2019 at 1:03 PM Michael Kjörling <michael@xxxxxxxxxxx> wrote: > > 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). Good suggestion. > > 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. Understood. As long as the recovery passphrase is not significantly more crackable than a reasonably sophisticated user's passphrase, they're not *worse* off with a recovery passphrase being set for them. And a sophisticated user could choose to use luksKillSlot to remove it. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
