thanks for the reply, hugo! good points. let me try to address them: i would like to avoid any dependencies for ssh as well. maybe if the user tries to use "--protect", only then would it prompt the user to install dependencies, such as the linux data protection service i'd like to create, which in turn may use dbus.
linux distros do encryption by default, but they don't actually start encrypting your files by default, so i'd say the ultimate default here is to not have anything actually encrypted. of course the experts will get their keys encrypted somehow, but i am worried about all my college friends who use ssh to sign into github but don't use passphrases. good point--to move keys, decrypting and encrypting in another form would be necessary. perhaps --unprotect would prompt the user to choose a passphrase for encryption during transport. yes, forcibly changing the user's password will cause data loss (unless the user still remembers the old password), but this is already the status quo on windows. you get a long warning message when you reset without the old password because all encrypted files and saved passwords are lost. gnome-keyring does the trick on linux, but for the feature to be popular and easy to use, pehaps it's better if it the solution is cross platform / built into ssh-keygen. thanks again! alex On 17 April 2014 01:40, Hugo Osvaldo Barrera <h...@barrera.io> wrote: > On 2014-04-14 00:28, alexander taylor wrote: >> I need advice on a contribution I'd like to make as part of my >> research with a cryptography professor at UC San Diego. I mostly want >> to know if there are any obvious practical problems with my idea. >> >> The problem I'm trying to solve is that casual users trying to ssh >> into Github or their home / school server may not bother creating >> passphrases for their private ssh keys. This means that they are >> probably relying on hardware security to keep their private key safe. >> However, with no added effort, these keys could be cryptographically >> protected under the user's Windows/Linux logon password in the same >> way that your saved passwords are protected in the web browser. For >> example, Chrome on linux uses any available keychain program to >> encrypt saved passwords under the user's logon credential, if a >> keychain program is available, and uses the Data Protection API on >> Windows. > > These features only work if you've all the right optional dependencies > installed, and a manager/daemon running that handles all that. > AFAIK, the GNOME and KDE implementation use d-bus, which I think would > be an unwanted dependency for SSH. > > Most "popular" linux distros do disk encryption by default. Especially > those used by the less tech-inclined users. > > OpenBSD users, and more tech inclined users generally know not to keep > their keys passwordless. Even if they do so, they already know the risks. > >> >> More on Windows DPAPI: >> http://msdn.microsoft.com/en-us/library/ms995355.aspx >> >> My idea is to add a "--protect" (e.g.) option to ssh-keygen that >> encrypts the private key with the user's logon credential (windows or >> linux password) instead of prompting for a passphrase. For Windows, >> it can protect the file using Windows DPAPI, but for Linux I would >> need to create a similar "data protection" service. This "data >> protection" service is also something I want to create, with >> ssh-keygen being the main motivation. The linux data protection >> service would generate a master key for the user, protected on disk by >> encryption under the user's password, captured by a PAM module. The >> same PAM module decrypts and re-encrypts the master key when the user >> changes her password. Then, the data protection service allows >> ssh-keygen to encrypt the private key using the user's master key, >> available only when logged on. Now, ssh can use the same service to >> decrypt the key if the user is logged on (another feature I'd need to >> add). If the user is not logged on, the private key is unusable. >> > > Sounds like you'd need a way to export the keys to move them to other > computers as well. Also, what happens if root changes the password? Does > the user lose his keys? > >> Using eCryptfs, hard-drive encryption, or simply making a passphrase >> and keeping it in a keyring solve the same problem, but require more >> effort by the user. >> >> More details on my research: >> https://docs.google.com/document/d/1mibuwHRJpzCFYuQJZ30Cgw6nBjyp6qod19tZnw-Rzv8/edit?usp=sharing > > You mention gnome-keyring as an example, that can double up as an > ssh-agent, and unlocks on login with the user password. I belive this > pretty much covers the initial scenario. At most, gnome-keyring should > have (if it doesn't already), an "generate ssh keys" option, and that > would cover the problem. > >> >> Thanks for any help/insights! >> >> alexander taylor >> > > -- > Hugo Osvaldo Barrera
