Hacker News Reader

    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.

It's worth noting that Debian distributions do, in fact, treat GPG as a core service--not for the purposes you describe, but for powering application installation. Ubuntu one-ups this by using OpenGPG for ppa-based installations as well.

Not what you're describing, but heading in the right direction.

Unfortunately most people blindly trust keys to get the software they want installed.

I think even this solution could go farther. Why isn't there a tool that automates all the checking of keys client side to check all this.

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.

This is what the 0install command does (it's included in the Ubuntu repositories). It will:

- 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:

http://0install.net/walkthrough.html

SELinux knows .ssh is special:

$ ls -laZd .ssh drwx------. user user unconfined_u:object_r:ssh_home_t:s0 .ssh

Exactly, MAC systems are the correct way to do this.

Good point. A lot of the security could be established on OS install, so the keys are immediately encrypted, permissions set, etc.

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.

GPG needs a safe sync process. Especially with it's mantra of "use many different keys", it is a colossal pain to actually try and keep the keys for different things synced across devices in a sane way (since it uses keychain files and not standalone files).

I too like the portability, but you should have a way to get import old keys in a way that is very trustworthy, but that also has you create a new key for all future stuff. Over time you could accumulate keys from the past that can be used to access archives, but you compute forward with a new key. Basically the tools should promote active and regular key rotation without losing your old ones.

Implied portability in what way?

PGP is built in to Linux as a core service, just not the way you're describing it.

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.

I'm talking about taking it far beyond just package managers like apt-get, pacman, rmp, etc., and beyond just software installation. I would love it if the usage of public keys got as far as allowing any browser to have access to your public key in a safe controlled manner so that it can offer your public key to any site you visit as an alternative to passwords.

Wouldn't that lead to facerape x1000?

Distributing your public key? No.

Edit - However you can't just use your public key as a password, but they could form part of a much simpler login process.

Which already exists.

Yes but I've never seen it done smoothly through a browser. It's OK, but not something I'd want my Mum to have to do to log into her emails.

Exactly this.

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[0]. 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.

[0] http://linux.die.net/man/1/ssh-copy-id

Are you suggesting that mkdir should know .ssh is special? I'm not sure that's a good idea. And how will the kernel (yes, it has to be the kernel) ask for a password when you access these files? With a GUI? On the console?

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.

No, I'm suggesting that the setup process for a new machine should include a step that creates .shh with mkdir and then uses chmod to set the permissions correctly, then possibly use another service daemon that boots on startup to watch for access to .ssh and manages showing you either terminal messages or GUI dialogs whenever any executable attempts to access anything in .ssh.

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.

Actually, a really good way to do this would be with a FUSE filesystem for such things. Then the kernel doesn't need to do anything at all. You could base it over the top of encFS or something like that.

I'm actually really tempted to do that now...