OpenPGP Blog

OpenPGP Bot on Twitter

Tue, 30 Nov 2010 17:00:07 -0500

For reasons I cannot entirely justify, I created a new Twitter account, @OpenPGPBot, that automatically retweets anything posted involving PGP, GnuPGP, or OpenPGP. Please follow if it’s your thing.

Encrypting the FreeBSD root file system

Fri, 22 Jan 2010 09:45:00 -0500

Encrypting the FreeBSD root file system:

Systems are only as secure as you make them. Thankfully, FreeBSD offers an excellent range of tools and mechanisms to insure that all your security needs are met.

Jacques Manukyan writes in the new issue of BSD Magazine. PDF download of the entire magazine available at the link.

PGP Corp. on Key Management and the Cloud

Wed, 06 Jan 2010 16:14:00 -0500

PGP Corp. on Key Management and the Cloud:

PGP Corporation’s Perspectives Blog offers some insight on how new cloud-based products can be secure and offer identity management (in a curiously unsigned post). The first generation of products we have seen centers on API keys, except for a few products which require you to submit your username and password for remote use. Both of these solutions are insecure for the same reasons.

Lately, a few cloud products at the bleeding edge of development have offered a new solution. GitHub, BitBucket, and Heroku have offered authentication solutions based on SSH keys. While these are development tools, their inherent focus on distributed data management suggests where next generation cloud services will solve authentication problems.

Using GPG to Sign Git Tags

Thu, 17 Dec 2009 17:46:48 -0500

Lately, I’ve been working in Git for version control and one of the more interesting features is the ability to sign source code tags. Git is a distributed repository system and consequently, it is impossible to know if a given copy of the repository is official in any sense of the work. Cryptographic signatures alleviates this problem and Git uses GPG to do it.

First, is is necessary to tell Git about your key:

howardjp@byzantine:~/src/git$ git config user.signingkey 0x3EE4249E
howardjp@byzantine:~/src/git$ git config --get user.signingkey
0x3EE4249E
howardjp@byzantine:~/src/git$

Then, create a tag giving the -s option:

howardjp@byzantine:~/src/git$ git tag -s commit.infodisplay 0839c680c7d2821753ae684874abf83aaaba6f32
.git/TAG_EDITMSG: unmodified: line 4
:a
This tag represents a finalized commit.infodisplay variable.
.
:x
.git/TAG_EDITMSG: 5 lines, 88 characters

You need a passphrase to unlock the secret key for
user: "James Patrick Howard, II"
2048-bit RSA key, ID 0x3EE4249E, created 2009-08-30 (main key ID 0xE6602099)

howardjp@byzantine:~/src/git$

Since my password was cached by GPG Agent, I do not need to enter it. And it’s that simple. To verify a tag, give a tag name and the -v option:

howardjp@byzantine:~/src/git$ git tag -v commit.infodisplay
object 589c8efd5bec637050ddaadae9471c15601738cb
type commit
tag commit.infodisplay
tagger James P. Howard, II  1261089522 -0500

This tag represents a finalized commit.infodisplay variable.
gpg: Signature made Thu Dec 17 17:38:42 2009 EST
gpg:                using RSA key 0x3EE4249E
gpg: Good signature from "James Patrick Howard, II" [ultimate]
howardjp@byzantine:~/src/git$

When Git signs a tag, it creates an object to represent the tag and also adds the entire history of the repository leading up to the tag. This is important because the signature then verifies an entire line of development allowing distributed sources trees that can be trusted.

Publishing PGP Keys in DNS

Wed, 18 Nov 2009 11:45:00 -0500

Publishing PGP Keys in DNS:

Dan Mahoney has written a new overview of publishing PGP keys via DNS:

Publishing PGP keys is a pain. There are many disjoint keyservers, three or four networks of which, which do (or don’t) share information with each other. Some are corporate, some are private. And it’s a crapshoot as to whose key is going to be on which, or worse, which will have the latest copy of a person’s key.

For a long time, GPG has had a way to publish keys in DNS, but it hasn’t been well documented. This document hopes to change that.

I do not work with DNS much any more, so I have not tried it.

Social Media and Identity Branding

Fri, 13 Nov 2009 13:20:28 -0500

This blog is about identity and social media touches on that. Small and medium sized enterprises (SME) are all over social media, and rightfully so. Social media provides SMEs the opportunity to level the advertising playing field and work directly with potential customers. And having a presence in multiple networks is equally critical, since the users are everywhere.

Quite a few, I’ve noticed, don’t get it. I have received a handful of friend requests on Facebook from businesses, despite the fact Facebook prohibits the use of personal accounts without a personal identity attached. Facebook provides a mechanism for businesses through “Pages.” But what surprised me recently was a business with a personal profile on LinkedIn, and it has 25 connections. The business also had a company profile on LinkedIn, which was up to date. SMEs would be better off using the business profile pages established for that purpose, as they usually are bettered geared at presenting business data. After all, you may be married to your work, but Facebook ought not say it is married to you.

Personal and Profesional Identities on One Key

Tue, 10 Nov 2009 10:00:00 -0500

OpenPGP provides the ability to associate a key with multiple email addresses. This is handy if you are both john.doe@example.com and jd@example.com at work and adding both identities to your OpenPGP key is best because you cannot control what address outsiders use for you. But you might also have a personal email account at Gmail or Hotmail. Should you add this identity to the same key as your work addresses?

If the key is only used to provide digital signatures, the only question is whether you want the email address to actually be associated with you. If your personal email address is john.doe@gmail.com or something similarly innocuous, you will be fine.

But encryption keys are another matter. If a recipient has multiple encryption subkeys on their OpenPGP key, they cannot specify a prefered key for any purpose. The sender is free to choose. So one subkey cannot be designated as professional versus another. As a result, an employer may well suggest that an encryption subkey stays with the business, since a subkey will always decrypt corresponding ciphertext, even if revoked.

There are a few considerations that suggest it may not be worth while, however. Encryption tools are not electronic methods for solving social problems. If an employee wants to steal data from the business, forcing them to use separate keys will not prevent them doing so. Especially since they may steal deciphered plain text or even the encryption keys. And employers may need to securely contact employees in a personal capacity, for instance, during a continuity of operations event, and establishing a consistent set of trusted keys for personnel can smooth communications.

Understanding Key Versions

Mon, 02 Nov 2009 09:26:33 -0500

Though not necessary for most modern users of PGP, understanding PGP key versions can enlighten other questions. There are two key versions which are relevant: PGP Version 3 (V3) and PGP Version 4 (V4). V4 keys were introduced by NAI’s PGP 5.0, which the OpenPGP standard is based on. The standard refers to V3 keys as “old format” and V4 keys as “new format.”

New format keys offer many advantages over old format keys. This includes the inclusion of many different subpackets that can be attached to a public key, sort of addendums to the key, which can specify information such as prefered hash algorithm, preferred key server, or revocation information. As GnuPG and PGP versions since at least 2000 have used new format keys by default, there is little concern here about which key format to use. However, some outstanding keys predate the OpenPGP standard and are still in use today. These keys are acceptable for use provided the owner accepts the key as their own.

GSWoT's Single Assurance Model

Mon, 26 Oct 2009 09:54:50 -0400

In contrast to the multiple assurer model, there is a single assurance model. The most interesting of the single assurer models is the Gossamer Spider Web of Trust, or GSWoT, which calls its assurers introducers. Like CAcert and Thawte, GSWoT introducers are volunteers who perform assurances as a part of other activities. GSWoT introducers, however, do not earn points and are drawn from the ranks of CAcert and Thawte assurers. This process enables GSWoT to recruit those already well-versed in identity management best practices.

GSWoT only works within the PGP web of trust by relying on the OpenPGP’s specification for depth of trust. GSWoT users can download the GSWoT keyring, which includes introducers, and a metakey for the entire GSWoT network. The user should issue a trusted signature to the GSWoT metakey with a trust depth of 2. The GSWoT metakey signs an introducer’s keys with a trust level of 1. From then on, the user who downloaded the GSWoT keyring will find valid keys for anyone signed by any GSWoT introducer. GSWoT introducers are expected to hold high standards when issuing signatures to ensure the Gossamer Spider Web of Trust does not become polluted. Additionally, GSWoT introducers cross sign each other’s keys to tighten the web of trust knot surrounding its volunteers.

There is significant overlap with both the CAcert and Thawte web of trust networks among GSWoT introducers. But unlike CAcert and Thawte, there is no single organization that continues to monitor and issue signatures representing the web of trust. Provided a copy of the GSWoT keyring, anyone can verify the validity of a signature indefinetly. For PGP users, the GSWoT keyring and the CAcert PGP key (which should be trust-signed with a trust depth of 1), provide a web of trust that is remarkably fault tolerant, massively distributed worldwide, and freely accessible by any Internet user.

Photos on PGP Keys

Thu, 22 Oct 2009 08:56:00 -0400

Earlier this week, I changed my profile picture on Twitter, Facebook, and other websites and decided the photo on my PGP key should match. This is a quick tutorial on PGP key photos.

PGP keys permit photos to be recorded on the key and are treated like other user ids, in that they can be signed by others. Image types are limited to JPEG. Generally, it is a set it and forget it process. So first we should remove the existing photo:

howardjp@thermopylae:/tmp/gpg$ gpg --edit --expert 0xE6602099

Secret key is available.

pub  4096R/0xE6602099  created: 2009-08-30  expires: never       usage: C   
                       trust: ultimate      validity: ultimate
sub  2048R/0xFCB31625  created: 2009-08-30  expires: never       usage: E   
sub  2048R/0xA40883BA  created: 2009-08-30  expires: never       usage: A   
sub  2048R/0x2C3602D7  created: 2009-08-30  expires: never       usage: S   
sub  2048R/0x3EE4249E  created: 2009-08-30  expires: never       usage: S   
[ultimate] (1). James Patrick Howard, II
[ultimate] (2)  James Patrick Howard, II <howard5@umbc.edu>
[ultimate] (3)  James Patrick Howard, II <jh@jameshoward.us>
[ultimate] (4)  James Patrick Howard, II <howardjp@gmail.com>
[ultimate] (5)  James Patrick Howard, II <jphoward@jphoward.com>
[ultimate] (6)  James Patrick Howard, II <james.howard@ubalt.edu>
[ultimate] (7)  James Patrick Howard, II <howardjp@terpalum.umd.edu>
[ultimate] (8)  James Patrick Howard, II (GSWoT:US72) <howardjp@gswot.org>
[ultimate] (9)  [jpeg image of size 18245]
[ultimate] (10)  James Patrick Howard, II <howardjp@miamialum.org>

Everything looks fine so far, so let’s select the photo as a userid and revoke it (from here, output will be abbreviated:

Command> 9

pub  4096R/0xE6602099  created: 2009-08-30  expires: never       usage: C   
                       trust: ultimate      validity: ultimat
[ultimate] (8)  James Patrick Howard, II (GSWoT:US72) <howardjp@gswot.org>
[ultimate] (9)* [jpeg image of size 18245]
[ultimate] (10)  James Patrick Howard, II <howardjp@miamialum.org>
Command> revuid

And now GPG will ask if I really want to do this, why, and give me the new key:

Really revoke this user ID? (y/N) y

Please select the reason for the revocation:
  0 = No reason specified
  4 = User ID is no longer valid
  Q = Cancel
(Probably you want to select 4 here)
Your decision? 4
Enter an optional description; end it with an empty line:
> Image is being updated.
>                        
Reason for revocation: User ID is no longer valid
Image is being updated.
Is this okay? (y/N)                  

You need a passphrase to unlock the secret key for
user: "James Patrick Howard, II"
4096-bit RSA key, ID 0xE6602099, created 2009-08-30

pub  4096R/0xE6602099  created: 2009-08-30  expires: never       usage: C   
                       trust: ultimate      validity: ultimate
[ultimate] (8)  James Patrick Howard, II (GSWoT:US72) <howardjp@gswot.org>
[ revoked] (9)  [jpeg image of size 18245]
[ultimate] (10)  James Patrick Howard, II <howardjp@miamialum.org>

So everything looks great, let’s add a new one:

Command> addphoto

Pick an image to use for your photo ID.  The image must be a JPEG file.
Remember that the image is stored within your public key.  If you use 
very large picture, your key will become very large as well!

Keeping the image close to 240x288 is a good size to use.

Enter JPEG filename for photo ID: jph.jpg
This JPEG is really large (44219 bytes) !
Are you sure you want to use it? (y/N) y

Since nobody actually reads keys to each other, I don’t mind a nice large color picture, but it is worth noting it is only 225x225 pixels.

Is this photo correct (y/N/q)? y        

You need a passphrase to unlock the secret key for
user: "James Patrick Howard, II"
4096-bit RSA key, ID 0xE6602099, created 2009-08-30

pub  4096R/0xE6602099  created: 2009-08-30  expires: never       usage: C   
                       trust: ultimate      validity: ultimate
[ultimate] (8)  James Patrick Howard, II (GSWoT:US72) <howardjp@gswot.org>
[ revoked] (9)  [jpeg image of size 18245]
[ultimate] (10)  James Patrick Howard, II <howardjp@miamialum.org>
[ unknown] (11)  [jpeg image of size 44219]

The validity is unknown, because it has not been recalculated yet. This is easy to fix by restarting GPG. Don’t forget to save your work:

Command> save

howardjp@thermopylae:/tmp/gpg$ gpg --edit --expert 0xE6602099
Secret key is available.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   2  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1  valid:   2  signed:   2  trust: 2-, 0q, 0n, 0m, 0f, 0u
pub  4096R/0xE6602099  created: 2009-08-30  expires: never       usage: C   
                       trust: ultimate      validity: ultimate
[ultimate] (8)  James Patrick Howard, II (GSWoT:US72) <howardjp@gswot.org>
[ revoked] (9)  [jpeg image of size 18245]
[ultimate] (10)  James Patrick Howard, II <howardjp@miamialum.org>
[ultimate] (11)  [jpeg image of size 44219]

Command> quit

And you’re done!

The Multiple Assurer Model of CAcert and Thawte

Mon, 19 Oct 2009 09:50:23 -0400

Identity assurance systems are surprisingly interesting. Two, which work in basically the same way, are CAcert and the Thawte Web of Trust. In each system, a person can register for a free account through the web and is then required to obtain points from assurers. Assurers work as volunteers, though some may charge small fees for their work. Many assurers are certified to grant points within both systems.

Assurers will meet with a person, and request to see photographic identification, such as a passport, and is required to document what type of identification is presented. The assurer may assign up to 35 points to the person met based on their own seniority in the system and satisfaction with proof of identity.

Once a person has collected at least 50 points, either system will issue them a signed X.509 certificate the person can use for S/MIME email or certificate-based logins, that includes their name and email address. If a person can collect 100 points, they may themselves become an assurer within the system The requirements for multiple assurers’ certification prevents a single rogue assurer from poisoning the well of certificates issued by the system. At least two assurers are necessary. In these respects, both CAcert’s and Thawte’s systems are identical.

There are several differences worth noting. First, Thawte certificates are widely accepted by the default configuration on desktop PCs. However, CAcert certificates are not widely accepted and will only be accepted if the user has installed CAcert’s root certificates. CAcert is aware of this and pushing for inclusion in more software. CAcert also issues website SSL certificates for servers, and code signing certificates for applications developers.

Additionally, CAcert offers PGP key signatures for verified email addresses from the CAcert PGP key. CAcert’s PGP certifications are available to users with at least 50 assurance points.

Last month, Thawte announced the termination of their service and offered users a free one year certificate through Verisign. The service no longer accepts new enrollments.

The above was written primarily before Thawte’s announcement.

The PGP Global Directory Verification Key

Thu, 15 Oct 2009 09:24:00 -0400

Below is a highly abbreviated output of gpg --list-sigs for my public key, 0xE6602099, specifically the output for user identity jh@jameshoward.us:

pub   4096R/E6602099 2009-08-30
uid                  James Patrick Howard, II <jh@jameshoward.us>
sig 2      1 3C4A1809 2009-09-02  GSWoT - Gossamer Spider Web of Trust
sig 3      1 6126D1F5 2009-08-30  James Patrick Howard, II
sig     P    65D0FD58 2009-08-30  CA Cert Signing Authority (Root CA) 
sig       X  CA57AD7C 2009-09-03  PGP Global Directory Verification Key
sig       X  CA57AD7C 2009-09-16  PGP Global Directory Verification Key
sig 3        E6602099 2009-08-30  James Patrick Howard, II

One signature worth noting is the self signature from 0x6126D1F5. This offers users of my public key assurance that I approve of tying this user identity, including the email address, to me. Two others, from 0x3C4A1809 and 0x65D0FD58 are the root keys for the Gossamer Spider Web of Trust and CAcert, respectively.

But also included are three signatures from 0xCA57AD7C, the PGP Global Directory Verification Key. PGP Corporation runs a unique keyserver, that unlike others, does not retain historical data. The server will send an verification message to each email address on the key. Once an address is verified, the Global Directory records this for future use. When downloading a key later, any verified address is signed at download time by the PGP Global Directory Verification Key.

The unique aspect of this is the short time to live for these certifications. Signatures from the Global Directory are set to expire two weeks after creation, though they will be recreated the next time the key is fetched. As a result, some keys in the wild have numerous PGP Global Directory Verification Key signatures embedded. For instance, the most recent copy of the CAcert key above has 114 certifications from the PGP Global Directory included.

PGP acknowledges this method of verification has limitations. But for a first level identity check, especially when the email address is known and available, this method can provide a quick and dirty check for a valid key.

An Inaugural Post

Mon, 12 Oct 2009 19:41:11 -0400

This is a new blog dedicated to OpenPGP and related topics. OpenPGP, itself, is a standard for encrypting and signing digital data. Some of the related issues might include identity management, X.509, and even social media.

I started this because so much of the material surrounding OpenPGP is so poorly documented. While several books exist, they do not provide much insight into the nuances of signing data and none provide a lot of resources for those interested in more than encrypting a few emails.

This blog will cover a lot of topics from key generation and types to certificate authorities and probably some other interesting things coming over the horizon. Posts will probably run about once a week, usually on Tuesdays.