thank you giancarlo! sorry i hadn't known to look for inline responses when i read your first email, which i read on my phone.
ok, so i had some trouble formally expressing an attack scenario, but i'm glad you agree that crypto is important and underused even for some non-casual users. actually i want to protect everyone in the world like me who don't want to keep track of another password, will always prefer default options and are scared of full profile/disc encryption, but could still benefit from crypto in case their device is stolen or tampered with (and they know it's been tampered with soon after the fact), so not just my college friends. i think overall this feature would still add utility. i'm glad ecryptfs is just a matter of checking a box, but i think there is a reason why people don't check it. for me it is because i'm afraid of losing all of my files if something goes wrong (forget the password, delete the key on accident). you're certainly right about repeated physical access. but i wonder about how much more difficult it is for the adversary to deal with cryptography in a practical situation. as an example, i could install a keylogger on the machines at my school, but this takes more time than i have, and leaves a trace that may allow me to get caught. however, as it is, i can copy the plaintext file onto a flash drive without leaving a trace. so, the crypto would be at least a little bit helpful, and not a false sense of security for people smart enough to be able to use ssh anyway. i will have to devise a realistic and scary threat model. very interesting point about portability. i was hoping that ssh-keygen could prompt the user to install the necessary dependencies if they try to use the --protect feature, instead of having package dependencies. also, since it couldn't be implemented for every platform, perhaps it could simply say that the feature is not supported for that platform. not sure if practical. i'm glad you like the linux data protection service idea. that would need to come first anyway so i can focus my initial research on that if the ssh ideas seem unlikely. thank you for your time and ideas! On 17 April 2014 08:44, Giancarlo Razzolini <grazzol...@gmail.com> wrote: > Em 17-04-2014 08:05, alexander taylor escreveu: >> thanks for the reply! i am trying to keep the keys safe in the >> scenario whereby an attacker steals someone's computer, takes out the >> hard drive, mounts it in another machine and bypasses access rights >> specified by the filesystem. >> > If this is what you're trying to accomplish, you're better off > instructing your friends and colleagues to using full disk encryption. > On windows there is bitlocker, which I advise against but is on the > system right after installation, and there truecrypt, which is better. > On mac there is filevault, but it does encryption on file level rather > than disk level. On linux there is dm-crypt, luks, ecryptfs, and > probably some more options out there. On OpenBSD there are options also. > The benefits of having full disk encryption go way beyond of just > protecting a ssh key without a passphrase. > > It's worth noting that if an attacker has repeated physical access it's > pretty much game over, even with FDE. There are way too many attacks he > can do, the evil maid being just one of them. Also, in the case of > theft, if the FDE password is weak and you're just using a password > (truecrypt, luks, and others can have one or more keyfiles) there the > old fashioned brute-force attack. > > As I mentioned before, I think it will be very difficult for you to > implement a solution that is portable across all the platforms. And > probably even if you can, I don't see it getting into upstream OpenSSH. > Now, the data store you are wanting to implement for linux is a good idea. > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC
