Re: pashphrase management question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Am 26.10.2016 um 23:40 schrieb ClEmFoster:
On Wed, October 26, 2016 3:21 pm, Sven Eschenberg wrote:



Am 26.10.2016 um 23:08 schrieb ClEmFoster:

On Wed, October 26, 2016 2:39 pm, Michael Kjörling wrote:


luksChangeKey <device> [<new key file>]

Changes an existing passphrase. The passphrase to be changed
must be supplied interactively or via --key-file. The new passphrase
can be supplied interactively or in a file given as positional
argument. /.../ <options> can be [--key-file, --keyfile-offset,
--keyfile-size,
--new-keyfile-offset, --new-keyfile-size, --key-slot].



That should be all you need.


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.


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.


I think keyfile and Passphrase are being confused here.


No, they are pretty much the same, with some constraints however. The actual key is encrypted by the passphrase, a disk can (obviously) only have one encryption key.

This whole disk OS is not booted yet when an admin has to type in the
passphrase.  Once the OS is running it is true a keyfile could be used but
then it would also have to be rotated.  I am looking to change the
passphrase on a 100+ machines utilizing some kind of automated system.  If
I didn't have an IDM I could generate the hash for any given user and
automation could edit the shadow file.  I was looking for something
similar, where I didn't have to have a plain text passphrase sitting on a
central server.

You are misled in the principles of operation, I think. A password, that is hashed, can only authenticate, LUKS however does not use passphrases to authenticate, but to reconstruct the key - Simply put, your passphrase decrypts the actual disk key. Thus your passphrase itself becomes a key.

You are free however to do what you want outside cryptsetup, you could use the passphrase's hash as passphrase and store that. When a user inputs the passphrase, hash it first and then hand it over to cryptsetup.

You can store the passphrase in a keyring (central location) and have a copy of that on the target machine. The user then unlocks the keyring to retrieve the passphrase for cryptsetup.

I can think of further options, but it all depends on the exact goal.






--
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






Thanks


Travis


_______________________________________________
dm-crypt mailing list dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



-Sven
_______________________________________________
dm-crypt mailing list dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



Travis

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux