[dm-crypt] pashphrase management question
michael at kjorling.se
Wed Oct 26 23:55:16 CEST 2016
On 26 Oct 2016 23:21 +0200, from sven at whgl.uni-frankfurt.de (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
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
More information about the dm-crypt