On 16/04/2020 04:03, Dan Farrell wrote: > The reason I want this is be have the option of entering a password manually, or have it automatically provided by a program at the same time. > > So the idea is, for example, I turn on my laptop and either type the password, or insert a security token. The password helper program would interact with the token, and provide a password from it. > > Does that make sense? I realise it is a bit silly, but relying on systemd to provide a password seems suboptimal. It's just an easy way of getting vendor specific USB support without he libs in cryptsetup itself. Well, that's exactly what we tried to solve with "tokens" struct in LUKS2 metadata. (Token says "how the unlocking passphrase could be retrieved".) If there is a token defined, cryptsetup tries to use it, if not, it fallbacks to password query. (Currently only internal keyring token is implemented. IOW it tries to check keyring, if it is not there, it fallbacks to password query.) Later we allow dynamic token handling. (You can do it today if you compile own application, libcryptsetup API allows it, but not commandline cryptsetup.) This way the policy (and keyslot priorities) is stored in LUKS2 metadata. For LUKS1, you can easily script this outside of cryptetup (check if token is available, then pipe output otherwise call cryptsetup without piping input). Or see below. > But for sure I won't take any offence if it's a no go, I can do it for my own systems easily enough. TBH I think you are implementing something that can be done with named pipes already (you can use named pipe for --key-file). Try: # mkfifo pipe # cryptsetup open <device> <name> --key-file pipe & And now just write to the pipe what you want (either manually ot through token): # echo -n <passphrase> >pipe (Note it processes EOL as part of the keyfile, so you need to avoid it.) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
