I would love it if the .ssh folder was also protected by default so that I would know if any application every accessed it, I would be notified. I know they are supposed to have permission 600 and normally won't be trusted if they don't. Because of this, I've always thought it odd that they aren't created with the correct permissions by default, instead of requiring you to explicitly change it. I've also always thought it odd the .ssh folder and files just as the .netrc file are not encrypted secure files by default that always require a password to access or at least require a password to access at least once every 5 minutes or so (like is sometimes required when running another sudo command past a certain threshold.
If one of the Linux distros never take the lead here, it would be sweet if OS X were one of the first ones to lead the way on legitimizing public/private key generation and exchange by making it much easier, but still secure.
If they are such a great solution, why isn't PGP built
into Linux as a core service? I'm not talking about
simply having it available as one of the standard
packages. Instead I'm talking about making it standard in
tons of normal interactions.
Not what you're describing, but heading in the right direction.
For example, when I download a binary or source package from some site with a corresponding file full of SHA1 or MD5 hashes, why isn't the presentation and serving of these keys sufficiently standardized that downloading the file can trigger and automatic download and hash comparison and then pop up a dialog that shows whether or not the file checked out ok. The process is so incredibly manual s that's very likely that most people will not check keys and signatures. The SHA1 or MD5 file could be completely standardized for the files served from the same URL folder root and have a standard recognized filename just like index.html or robots.text.
The system could first be designed to make it completely automated to check hashes and signatures. The next step would be to start building in layers and tools for the web of trust so you can also confirm that the signature your are accepting is also trustworthy. To get to a true web of trust, you need to slowly build up the foundational infrastructure for it, layer by layer.
- Download the package metadata
- Download the GPG key
- Check the metadata's GPG signature
- Confirm the key with the user and/or check against a key information server
- Download and unpack the archives
- Check the tree digests against those in the metadata
This page explains what it's doing behind the scenes:
$ ls -laZd .ssh
drwx------. user user unconfined_u:object_r:ssh_home_t:s0 .ssh
Similar to gnome/OSX's keychain. Allowing integration for app devs via standardized processes. I like it.
The only issue is PGP's implied "portability", so generating a new key for each box is not sufficient if I want to open old emails. A (safe) import process would be necessary.
The vast majority of distros (Anything DEB or RPMS based, and I'm sure others) distribute software authenticated with GPG.
Gnome already makes it quite easy to utilize GPG -- support is built in to the Gnome Keyring as well as a number of build in Gnome utilities (I imagine KDE has a similar mechism in KWallet, I just haven't used KDE in over a decade).
The reason you're not noticing widespread use is because OpenPGP has been made quite transparent most places it is utilized.
Edit - However you can't just use your public key as a password, but they could form part of a much simpler login process.
Take the github process for getting your public key for example. I as a user need to go to the github user settings (probably after getting a warning at the command line or wondering why the command line process is so disjointed) and find the tab for adding my public key. Once there, if I don't yet have a public key I need to generate one, which requires reading instructions on how to do so. Then I need to copy the .pub file (someone uninformed might not understand them fully yet and try to upload the private one by accident). This entire tango might be acceptable for you and I, but not for most people who are probably struggling on the first step and figuring out on their own what PGP is to begin with.
At the end of the day, this is just a really convoluted way of doing exactly what ssh-id-copy(1) does. Hardly something my mother could do. What we're suggesting is building the ssh-id-copy(1) process into the browser as a W3C spec, which would allow me to show up on a site and quickly and safely copy the public key of my choosing.
It is precisely the lack of such integration with a distributed auth technology that has made centralized auth technologies like OAuth with Facebook and Twitter much more attractive than they should have even been.
So you don't want Firefox to be able to read SSH keys. Privilege separation and sandboxing is the correct solution to this problem. Full disk encryption will protect the data at rest.
I think firefox should be able to access SSH keys as should any other application, but I should be notified when this is going to happen. From there I should be able to trust an application indefinitely so long as it's executable doesn't change (i.e. maintain shasum hashes of any trusted executable and make sure that if the shasum changes, you are informed that it has changed. e.g. "The executable Foo has changed since you last trusted it, would you like to trust it again?"
Privilege separation and sandboxing is the correct solution, but there is no reason that these cannot be improved upon to make this more friendly but still secure. Accepting the status quo solutions is akin to accepting that it will always remain a niche solution that never gains acceptance and traction in other areas of our lives where we want security and a solution that is inherently decentralized.
I'm actually really tempted to do that now...
Here is my question at stackoverflow: http://stackoverflow.com/questions/19683880/pgp-signature-ch...
Just another example of how unnecessary coupling is thwarting new uses.
gpg --verify ...
rm -rf $GNUPGHOME
Do this but but don't do that oh and make sure about that, and this, and that....
To be honest, signing other people's keys is one of the _more_ frequent activities I do with PGP, and I'd rather be able to independently revoke that key without tossing my identity.
Have a look if that helps you!
I'm involved in a project to produce a cheap hardware widget to make this kind of thing easier (http://cryptome.org/2013/10/bitcoin-usb-gpg.htm) but it is not yet in production.