OpenPGP

From IndieWeb
(Redirected from gnupg)

OpenPGP (Pretty Good Privacy) is a message exchange format that uses public key cryptography to enable people to exchange encrypted and/or signed data; on the IndieWeb, you can use PGP to setup your IndieAuth without depending on any silos.

Whilst most often used to encrypt email, this page discusses indieweb uses for PGP.

Terminology

Pretty Good Privacy (PGP)
This is the name of the original software created by Phil Zimmermann in 1991. It is now owned by PGP Incorporated.
The acronym "PGP" is commonly used as a catch-all when referring to this encryption format, though "GPG" is often the more technically correct term.
OpenPGP
This is the name of the open standard for PGP encryption, proposed by Zimmermann to the IETF. The current RFC is https://tools.ietf.org/html/rfc4880.
GNU Privacy Guard (GnuPG or GPG)
This is the GPL-licensed, OpenPGP-compliant encryption software commonly used. Since the current version is 2.0.30 (as of 2017-01-21, it is also referred to as "GPG2." There is also the 2.1 branch of releases, currently at 2.1.17 (as of 2017-01-21), these are sometimes referred to as “GPG21”

How to

Create a keypair

Link to your public key

  • Host the ASCII-armored public key on an https URL on your domain.
  • Add a link from your page(s) with rel="pgpkey" and type="application/pgp-keys":
    • <link rel="pgpkey" type="application/pgp-keys" href="/key.pub">

Key Lookup Algorithm

Draft, please refine.

Summary:

  • Goal: given a string identifier for a person (for example URL, email, twitter ID, key fingerprint), find their PGP key. Start with a decentralised approach, falling back to using key silos.
  • Try to derive a canonical URL representing the person, e.g. their website
    • If one is found, parse it for a representative h-card and use a non-URL "key" property as the person’s PGP key
    • If no h-card is found look for a rel-key
    • If an h-card u-key was found or a rel-key from previous step, retrieve it, use that as the person’s PGP key
  • else, query a either a keyserver or a key silo like Keybase to search for the user’s PGP key
  • otherwise: the user has no PGP key

Detail:

  • Given id, a string identifier representing the person
  • Is id a Twitter ID? If so let url be the user’s twitter.com profile page
  • Is id an HTTP URL? If so let url be id
  • Is id an email address? If so try a webfinger lookup on it.
    • If the webfinger lookup succeeded, let url be the person’s URL
  • Has url been set?
    • If so use rel-me to find the person’s canonical URL
    • Parse that URL for microformats including rel-key
    • If a PGP key is found, use that as the PGP key for the current user.
  • Otherwise, query keyservers/key silos of your choice to attempt to find a PGP key for id
  • If none is found, the person probably has no PGP key.

IndieWeb Examples

Public key on website

Exchanging encrypted messages

  • Aaron Parecki and Sandeep Shetty have exchanged private posts/replies encrypted using PGP, exchanging keys using Keybase [1]
  • Aaron Parecki posted an encrypted message to his website on 2014-03-18

    @kenichi_pdx

    -----BEGIN PGP MESSAGE-----
    Version: Keybase OpenPGP JS 0.0.1
    Comment: https://keybase.io/crypto

    wcBMAxLjTPAOaWECAQf+NFRUsLUx8BxxY98l4L07lE4gPSVo1FjinjNQAtM17SJx
    Y7MA2cSJkK3NFTkSK3cUZ9lRnaGdUrvAdYRUi2VRVL57ACXMuY0eu2Ia6EkP3iS0
    TKZAtrnA4Ne0JT1kd2PwCGRJddrg0jqNMx7er+Jm7LLepeHNLHGNJpuAeusx6KuL
    bvjDt5eV4AKqJxy5uCK3fdxXF7VniaIKtKi5eUDtWNBd2tRSMRh0rWVtDaeievV+
    djH6im8oanpYncNJryjTjTolj9V7Q6y7xnc6c80h3x0QHmKQdBFOyjfVodCM9awD
    1RO/01aq6WUEWIuRcDOWZsOwO1RlOUoUu/hTXHI9LNLBLgF3CWloeEnZs2ZuiM0n
    b7GrM0tTlcKDQrqg3XlQkZ6fekV60IHodjNPakFJ+AZJNOHM8RZzD06L153/mmTc
    jfWjfEC4iiv4XLcfE2eyjcXkkfpoiDcmoi1x0APkMwIQruWhiWe/V1kXS/7skanc
    qUobGC9HffD7iNz0Pb+5/Ki1Q3aWq1eA6gBePf3DkFEo4PnqWGH3coKcvTexO9dJ
    yV4DOmi1n0MT+C4iinnmrh7Z2t5d25Vp5FuaXpontjLH5i9OsYxO0NZiCq6PY7Hf
    9buLMMsStzawC/2J0D87AIJq+zf+SfBrah3S1cLsjcBsN45Pd31jeJDbdUusKRfT
    miMDOWliEWayt6PTr8yqUD6mhFYF5ugY3vOtQLz3D4oK9djKg8FkNga+TwOJJUa8
    /VLlJ8WMYKAG5hOd+n22OLUlIkeobjnwdodfc7rwMQB4fuJH0RiPGVed4RWbxGjj
    TUxu4itow9nfLlXjj7x1tx7VBvI1H/PPWhLNY5PHeIJ/JxPVDubUhnNjfMhjFkkh
    cjUfau+FfuB36r0XBNpbL2uat3uCCBwctaZvWZo5q9w42us2kaLVFHBYQFlOCTVW
    AeaNjkgNwg34FHsUNjcvnZ716mYQCaSBeXC6hMnrxsRLJwkmLgafc6jMJtpfItTN
    =Gjt6
    -----END PGP MESSAGE-----

  • Dr. Matt Lee points to Enigmail which is the way to do it in Thunderbird and Thunderbird is cross platform.

Secure communication

What does "secure communication" between two or more entities really mean?

An entity can be a person, software running on behalf of a person (eg: an app) or an online service (eg: a login service.) Let's just call all these things 'parties'.

Focus on three areas.

  1. Authentication - can one or more of the parties prove to their satisfaction that they are talking to the "right" party?
    A login service is an example - it wants any any party talking to it to prove according some definition it cares about (like IndieAuth) - they are who they claim to be.
  2. Integrity - can one party ensure to their satisfaction that a message received from the other party hasn't been tampered with?
    An example is a download of a security update of some software, normally accompanied by a digital signature.
    You might also want something comparable for webmentions, especially if you embed content from your friends site into your own site. You might prefer picking up only verified portions of content created by a person you trust; rather than worrying whether you've accidentally picked up xss content inserted by someone who's hacked into their server.
  3. Confidentiality - can the parties communicate with each other with some well-understood guarantees on who can read their messages?
    An example might be PGP-encrypted email - anyone who has the private counterpart of the keys they are encrypting against; anyone who has access to the machine where the decryption occurs; anyone who finds a bug in a specific implementation of the software -- all these people can read their messages.

RealPolitik

Secure communication occurs within a messy interaction of four motivations.

  1. How valuable is a piece of data to the party who owns it.
    Eg: A person with an indieweb site often hosts public data about themselves, and might not feel much desire to "protect" such content. They may however, also have data (private photos of their family, say) that they might feel is more valuable to them.
  2. How much effort is the party willing to take to protect their data.
    Most people use a sliding scale. eg: financial statements - more effort to protect it. Private photos - if they are creeped out by the thought of someone else looking at them, they might take some extra effort. Blog posts intended for public consumption - not much at all.
  3. How desirable is the data (or access) to an attacker.
    eg: An attacker might find a vulnerable indiewebsite as part of a botnet; rather than be interested in any data on the server itself. Or, they may find it gives them access to a more valuable site - say it has OAuth tokens that allows access into the owner's email and enables password reset into a bank.
  4. How much effort is the attacker willing to get to the data.
    If an indiewebsite includes a widespread vulnerability, it might take little to no effort to get into the site, regardless of the content on the site. If they find a valuable site (say, it hosts private messages between well-known net personalities) they might be willing to invest more effort to acquire the data.

So any solution should identify and solve specific threats, and stay within the level of effort people are willing to invest in it. eg: software that uses military-grade OpenPGP is as good as no security, if using it is so hard that nobody uses it at all.

Authentication

How to use PGP for Authentication

Provide a link to your PGP key from your home page with a rel value of "pgpkey". Then, when signing in via indieauth.com or other implementations, the site will provide a challenge that you can sign with you private key.

Full details: https://indieauth.com/gpg and https://indielogin.com/setup#pgp

Brainstorming

Alice is using her contact manager to add Bob to her contact list. The contact manager has figured out Bob's canonical URL, and also found a key from (say) hCard data on the site and is ready to add it to her contact list.

How can Alice increase confidence that this key is really from the person she knows as Bob?

If Bob uses indieauth on his site, a simple check would appear to be for the contact manager to verify and display the mutual rel-me links to the various 'major' silo providers. Alice could quickly check if they point to the "correct Bob" within the silos.

However, an indieweb site runs with decreased security; and some threats are:

1. the site may be malleable - the attacker silently changes data or links on the site before it is noticed. For instance, the key may be changed, leaving the rel=me links intact.

2. the site likely doesn't use TLS - so traffic may be modified similarly, without either party being aware of it.

...Other realistic(?) things to add?...

In either case, a key obtained from the site should be treated cautiously before choosing to use it.

Are there further simple checks Alice's user-agent can perform, that would otherwise be tedious for a person to do manually?

Approaches

Many people already tweet fingerprints of keys as proofs of ownership of a given key.

...thoughts?...

A better approach for fingerprinting - Bob still adds rel-me links to his canonical URL as before, but adds his key fingerprint to the linked profile page on g+, twitter etc. This lets Alice's user-agent automatically match fingerprints on the linked rel-me pages.

Now an attacker must be able to edit both the silo's profile page and Bob's canonical page to fool Alice.

User:Ben.thatmustbe.me pointed out that many POSSE sites store tokens to push to twitter etc; so an attacker might actually be able to modify both sites. He suggests it's best to validate at least one rel-me link to a silo whose profile pages are unlikely to be automatically editable by a typical POSSE site. Google+, github?

Bob can also markup links to various tweets/posts/github gists etc. from his canonical URL with something like 

   <a rel="key-fingerprint" href="...">..</a>

Alice's contact manager can choose to follow these as "additional proof", if it knows how to reliably obtain the silo's owner from such links. eg: a github gist url.

Examples of indieweb users using this mechanism to offer keys along with linked fingerprints to silos - Barnaby Walters, Kyle Mahan, KB Sriram.

KB also has some prototype code that shows and validates such PGP keys and fingerprints, and displays them as follows.

User:kartikprabhu.com suggested Webmentions - another approach to match fingerprints from trusted sources?

The contact manager shows identities from the fingerprint-matching pages as "confirming" the key, and Alice looks at these to decide whether to add the key.

Prior to each use, the contact manager can also recheck the canonical site (and confirming urls) and flag any changes - trust-on-first-use-then-verify, aka ssh. This would also address situations where Bob wants to publish a new key.

Integrity

When accessing content from an indieweb site (say) for the purpose of extracting the text for a webmention, how can I reduce the risk that the page was not hacked in some way? I don't want to extract things that might contain malware links or xss content inserted by someone who's managed to hack into their site.

I have to rely that the other person maintains a secure website at all times, or if the roles are reversed - that I have to maintain a secure site at all times; which seems an unreasonable demand for a typical indieweb site.

One approach, at least for static sites where content is generated first on the user's local machine, is to attach a digital signature alongside the content before uploading it online.

For example, a page could have something like 

   <link rel="signature"
         type="application/pgp-signature"
         href="page.html.asc">

pointing to a signature alongside the file. An example from KB's site where each page is linked to a signature.

Tantek also suggests a link to a signature could be provided from HTTP headers rather than the html page itself.

Confidentiality

Private, Transient, Async Messaging

This is related to private_posts.

Problem

I want to send a quick note/photo to one or more of my family or friends. I'm not chatting with them - just something they can look at when they get around to it. I trust them enough to not redistribute it without my consent.

The data is not valuable financially, and best-effort delivery is also fine. I just don't want anyone else to be poking into it [eg: photos of kids, or a private discussion about someone.]

It's important that all of us can send or receive messages from any of our devices (eg: phone or laptop.) Also, I'd like the data to have a short expiry time in the cloud if at all possible - snapchat-ish, at least in the cloud.

How can I set up an indieweb system that lets me do this conveniently?

Threats

Because of its async nature, the content has to stored on the cloud somewhere. I want this data to be "safe" even if it were accessed, or archived and examined by anyone.

That is - I'd like to have endpoint-to-endpoint security - an attacker has to put malware on the device (or gain physical access to it) before they alter or look into the messages.

Possible Solution

One solution to that could be called pgp messaging.

Jacky Alciné 2022-09-30: I think that building clients that do some sort of message signature checking should also take care around the caching policies of responses as well as using a token to view each specific resource for a fixed amount time can do a lot of the work here. Nothing we can do can stop people from taking a picture of something from another device. A mix of any sort of prenegotiated secure messaging layer (OEMEO, PGP, argon2) mixed with the above is a good way to go.

Goal

Alice (alice.com) wants to send a private message to Bob (bob.com), and bob has a public key with the fingerprint '1234'.

Protocol

Alice creates an url for bob like https://alice.com/1234/index.html.

On this url, Bob will find an encrypted html page with a redirect to a secret URL. For instance, it could be: https://alice.com/1234/NewBase60_charset_obscure_url.html. The encrypted redirect and the final endpoint are encrypted with Bob public key.

  • redirect is necessary if Alice wants to protect how often she updates content to Bob.
  • https is mandatory in this case as this will hide the obscure url.
Notification

Alice can send a webmention to Bob to notify there is new content. It could also be an RSS feed that Bob fetches from time to time.

Advantages

The advantage of this solution is that it could work with static and non static sites.

Alice could also hide that she is in contact with Bob by answering a kind of encrypted messages for every https://alice.com/fingerprint request. (Alice has to take care that her server takes same time to compute both answers - for a real fingerprint, or a random one)

Disadvantages

This solution requires a pgp plugin on your browser or your indiereader would need to have access to your private key. In the case of the indiereader, if it is not hosted by you, it would be a good idea to use an 'indieweb' sub key, signed by your primary key (Using subkeys).

Concrete Example

Pierre-O wants to share private information with Barnaby Walters.

Here is a link without encryption it is for demonstration purpose. In real life, there would be just files with pgp extension.

The same link with encryption.

As you can see, Barnabywalters uses his fingerprint to be redirected to an obscure URL that just him with his private key can know.

Then the interesting thing is that, I can share my phone number with him, thing I don't do on my public profile. I can share posts and send him webmention, and he can subscribe to an encrypted rss feed.

Criticism

May not help email security

Fastmail explains why they don't offer PGP - in short, it won't actually improve email security for their users, so they don't bother with it.

Latacora writes about how email is inherently unsafe and how just putting PGP (which they describe as “a deeply broken system”) on top of it is not going to help solve anything.

The least interesting problems with encrypted email have to do with PGP. PGP is a deeply broken system. It was designed in the 1990s, and in the 20 years since it became popular, cryptography has advanced in ways that PGP has not kept up with. […] Even after we replace PGP, encrypted email will remain unsafe.

Certificate flooding breaks key servers

Articles and Guides

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=OpenPGP&oldid=96948"