On Mon, Jul 01, 2013 at 12:56:40PM -0400, .. ink .. wrote: > > That means this whole scheme is about as secure as a locally stored > > passphrase, i.e. not secure at all. The only benefit a remotely > > stored passphrase has, is that if you take down the remote server > > _before_ the local machine is compromised and when the local volume > > is _not_ decrypted, you can deny the unlock. If the local machine > > is compromised while the remote server is running, or while the > > encrypted volume is mounted, the attacker gets everything. If > > the local machine is not compromised, you do not even need encryption > > to be secure. > > > > With that, I have the impression that the security model of this > > is fundamentally broken on a conceptual level. > > > > > if you have one static host that gets keys from one static server,then the > passwordless ssh method seem obvious but its pointlessness will shortly be > realized. To access the key from a different host machine,the private key > must be sent to the different host and the server,through other means,must > be informed of the new host and hence it seem pointless since the private > key could instead be used as a passphrase to unlock the volume or to unlock > a key protected keyfile. Well, yes. As I said, just as secure as a locally stored passphrase, i.e. not secure at all. ssh was just my first idea to get around the shorcommings of the webserver-based approach. But then I realized there is a far more fundamental problem. > There is another reason why such a setup could be useful and that is > convenience from centralization of keys. > > I dont manage my luks keys individually,i have them in kwallet and access > them through it.I have a bunch of luks volumes and i dont need to remember > their individual keys as all i need is the key to unlock kwallet. > > His use case could be the same,only he want to access a wallet that is not > on a local machine,but on a remote one so that he could smoothly switch > between devices he own and have access to his volumes keys through a single > key. Yes, but instead of a passphrase to unlock, he wants to use a device-supplied UUID (that hence is stored on the device on plain somewhere) and that is (as far as I can see at this time) basically the same as storing the passphrase locally in the first place as long as the remote server is available. If he would give a passphrase manually each time he requests a passphrase for a LUKS device, that would be something different. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
