On Tue, Dec 10, 2019 at 9:44 AM Philipp Rösch <philipp@xxxxx> wrote: > > Sorry for the late late reply. > > It was indeed the wrong keyboard layout. Imagine that... > > I was about to give up when I noticed different German layout variations on my live disk. One of those worked. Surprise. Interesting. If you have time to write up a brief summary with one or two screenshots demonstrating the confusion: in particular I'd like to see how the UI presents these two different layouts, how non-obvious it is, which one works and which one doesn't work. That would be great. I'm looking for clear examples of how users are betrayed by the user interface. Obviously if you had not persisted, and had resigned to data loss instead, it shifts the penalty of inadequate design onto the user. And that's inappropriate. > My case seemed strange because everything looked ok and there were no errors anywhere, except that the volumes wouldn't unlock. Yea, the likely cause for this is there may be no way of distinguishing between wrong passphrase and wrong encoding. I doubt the LUKS2 header contains any kind of hint as to what encodings were used when setting the passphrase. I'm curious if security experts could assess to what degree that information makes it easier to brute force attack a passphrase? Super simplistically, you have multiple layers of encoding between you+yourpassphrase, and the actual representation of that passphrase stored on disk. If any of those encodings change, it's functionally no different than entering the wrong passphrase. Same with all the other transforms done on your passphrase to make it stronger: salt, iterations, key derivation function. If those aren't correct every time, functionally it's the same as wrong passphrase entry. It's a binary outcome. 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. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
