On 26 Oct 2016 23:21 +0200, from sven@xxxxxxxxxxxxxxxxxxxxx (Sven Eschenberg): >>> luksChangeKey <device> [<new key file>] >> >> I did read that in the man page, but if you want a passphrase changed in >> that manor then you have to put the new and old passphrase in a file plain >> text. Unless I am missing something. I was hoping to fine some way to >> encrypt it before passing it in. like you can do with other applications. How about placing it in the LUKS container itself? You already have access to anywhere between gigabytes and terabytes of random access read/write encrypted storage, so might as well make use of it. > That makes absolutely no sense to me. Why would you want to encrypt > a passphrase? Or in other words, what's wrong with binary files? > Or don't you want to store the files on disk? Then be reminded: > STDIN and STDOUT are files, and can be connected to pipes. An alternative approach would be to create a temporary LUKS or dm-crypt container with a random key, store the passphrase files within that container, and when you are done, throw away the keys to that and delete the file from the file system. That way, even if someone gets full plaintext access to the outer container, and even if they are able to determine that you stored the passphrase in some particular location on disk, that data will still be unreadable. Or, if you don't want everything under the lock and key of symmetric encryption, take Sven's suggestion of pipes, and tie GnuPG with asymmetric encryption into the chain. That's the beauty of the Unix philosophy that every tool does one thing and does it well, instead of having monoliths that try to do everything and end up doing a half-baked job of most of it. We can perhaps help with the technical parts (though it would be nice if you tell us up front what you have considered and rejected, and why), but if we don't know what threat model is being protected (or attempting to protect) against, it's impossible to judge how well those meet the requirements. **If you don't even know yourself what the threat model for this is, then I suggest being up front with the people mandating this and asking them exactly what scheduled LUKS container passphrase changes is meant to protect against.** Something tells me that adding a handful of bits of entropy to the passphrase, or increasing the iteration count (especially since you say you reboot only rarely), is a better solution to whatever the problem is. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
