On Mon, Jul 01, 2013 at 03:54:32AM -0700, Alex Elsayed wrote: [...] > In addition, HTTPS/SSL/TLS (at least by default) has some real issues for > this kind of thing. SSH used blindly is likely to share some of them, but is > (fortunately) somewhat better understood and ships with better defaults in > most cases. SSH done right has full 2-sided authentication of users _and_ hosts. > Also, the whole question of authenticating with TLS vs SSH is the wrong > layer - you don't want to have any authorized machine get any key, you want > to tie the key given out *to* the machine. That is why I proposed separate accounts per machine. That ties the account to the machine, and the other machines cannot log into it. > That means either doing something > like gitolite, and linking the pubkey to the data it gets OR nesting Yet > Another Authentication Mechanism inside of the session, with all of the > (squamous, rugose) pitfalls involved in designing a cryptographic protocol > of any kind. Not needed, see above. However, there is another problem: If you need the local machine to authenticate itself to get the keys, you could just use the secret credential as passphrase instead, with better security. Anybody getting access to the machine with the storage can just request the passphrase anyways. 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. 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
