OpenPGP Best Practices | Hacker News Reader

OpenPGP Best Practices

we.riseup.net

116 pointsdoubleg31 comments

So one thing I don't get about PGP keys: 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. For example, the setup process for any new machine should require the creation of a PGP key specific to that machine. By adding this step, ever other application or service on the machine can go ahead and assume the existence of a private/public keypair specific to that machine. This opens up the opportunity for people to create applications that use public key exchange with the outside world as a given and therefore a reasonable default before passwords.

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.

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

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

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?

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

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.

Somebody needs to do a best practices for pseudoanon OpenPGP like being careful not to upload your key to a keyserver in the clear, unmasking yourself. Not using any identifying info while generating. As an example look at political or blackhat forums sometime and just examine the public keys posted: hotmail addresses and traceable user nyms. Also avoiding anybody who sends you a BCPG bouncy castle key or OpenPGP.js in the version header, because they are probably using some ridiculously insecure browser encryption addon.

Using pgp anonymously is really hard, esp because PGP has no integrated way to do authentication without non-repudiation.

Riseup's "Digital Security for Activists" goes into a bit more detail:

https://zine.riseup.net/

And submit your key to Phuctor: http://nosuchlabs.com/

While we are at it - anyone knows how to verify PGP signature with just the public key and withuot creating the keyring file? All the libraries I have seen verify signatures against keyrings - but I want to store the keys in a database and making a temporary keyring with just one signature to do the verification sounds like an ugly hack.

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.

Not exactly what you want, but perhaps something like this might help?

    export GNUPGHOME=/tmp/something
    gpg --verify ...
    rm -rf $GNUPGHOME
    unset GNUPGHOME

It's so damn easy to shoot yourself in the foot.

Do this but but don't do that oh and make sure about that, and this, and that....

Is there a way to have your master identity key offline and delegate even certifications (signing other people's keys) to a subkey?

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.

The Debian Wiki might have a similar use case here: https://wiki.debian.org/subkeys

Have a look if that helps you!

You need an air-gapped computer. An old (circa 2000 or so) laptop running some unix-like is probably best.

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.

Reply on news.ycombinator.com