This post will be a little outside the norm for my blog in that I’ll be reviewing software, an Alpha release from a company called Keybase.

Let’s start out by looking at public key cryptography between two individuals.  A work flow that is somewhat common and in today’s day and age, where privacy should be of the utmost concern between even the most basic of Internet users, but still somewhat difficult to achieve for anyone that’s not an advanced user.

Before we go any further, a level set.  This post will not dive into the working of public key cryptography, the differences between certificate based and an approach such as GnuPG, or the pros and cons of each beyond what’s needed to illustrate various points.  There are multiple posts online that cover these topics and I encourage you to become familiar with them if you are not already.  I am also simplifying some aspects of how public key cryptography works in order to convey a point to the widest possible audience.

So, for our scenario let’s say that Bob wants to send Alice an encrypted message.  By the way, Googling for Bob and Alice will give you some great tutorials on how public key encryption works, but to continue.  Bob has a public and a private key.  Using GnuPG Bob publishes his public key to a key server.  This provides Alice a distributed source, and easy access to look up and download Bob’s public key.  In order for Bob and Alice to communicate they each need to know the other’s public key.  This is a basic requirement in public key cryptography.

Figure 1

Figure 1

 

Using Figure 1 as a starting point, how does Bob know that the public key on the key server does in fact belong to Alice?  How about vice versa?  If they know one another they could verbally confirm the fingerprint of each public key to the other, but that assume that Bob knows Alice before hand.  What if they’ve never communicated before?  Then it gets a little trickier.  (This is where I’m simplifying things a little, there are other methods but they are manual in nature or require a deeper understand of how the process works.)

Taking this a bit further, and updating the Bob and Alice story with more of a 21st century feel, let’s say that Alice is an avid social media user, tweets and blogs frequently, and Bob reads her posts often.  Alice has a persona now in Bob’s eyes.  She has a name, a Twitter account, a blog, and even a Reddit account that Bob finds useful from time to time.  To Bob though, that’s all he knows, her online persona.

Figure 2

Figure 2

However to Bob, Alice now has a personality.  She’s not just a public key on a key server somewhere, lifeless.  She’s a living breathing human that he reads and enjoys daily.  That being said, and to make it interesting, let’s add just one more piece to the puzzle and tie it all together, her public key.

Figure 3

Figure 3

Please note here that my use of the word Persona is my choice, not one that Keybase has chosen to use.  Allow me the latitude as I describe the point in more detail.

Alice has a Reddit, Twitter, Blog and a Public key, but how is this all relevant for Bob?  What Keybase has done is devise a way to cryptographically “link” all these disparate things together into a single, verifiable, entity.  The validity of Alice’s public key can now be asserted at a level higher than previously possible due to the connection of her Twitter, Blog and Reddit accounts.  Entities that Bob uses daily and knows.  Her public key is no longer a lifeless bunch of bits on a key server, it’s a breathing assertion of who she is online.  What you may be asking now is, how does this help?

Say one day Alice posts something on her blog just too good to not comment on, but Bob doesn’t want others prying into his conversation with Alice on the topic.  Bob thinks he will encrypt the conversation, but how, he doesn’t know Alice or have any of her details to even begin to start an encrypted conversation.  This is where Keybase steps in.  Utilizing their website, or a convenient set of command line tools (I’m certain this will be integrated by way of their API into an app of some sort soon) Bob can look for Alice using what he knows.  Bob searches on Keybase.io, the Keybase online site, for Alice’s website.  Once found he can type and encrypt an message to Alice, right there on the site, using her public key.  (In the near future the site will offer the ability to e-mail her that message too).  Bob could also utilize the command line to look up and encrypt a message to Alice in the same manner.  All without knowing anything about her other than a blog site he frequents often.  The same example holds true for Twitter, Reddit, or any other linkable entity in the profile.  Simple and effective.

One might ask how this is different than public keys on a key server in terms of validity of the recipient.  It’s all shades of what you accept.  If you really want to exchange messages with a second party you don’t need all of this, but you do need a way to verify the ownership of the target of your message.  If you don’t know the person that can be difficult.  What Keybase has done here, rather ingeniously I might add, is tie other factors into the equation for you to consider.

Stepping away from the Bob and Alice analogy let’s look at something real.  Go, right now, to https://keybase.io.  Go ahead, click it, the page will open in a new tab.  Now, in the search bar up top type in the name of this blog, vmfieldtips if you don’t remember how you got here.  (Leave off the www. and the .com, remember, it’s Alpha)  You’ll see a search result like below.

Figure 4

Figure 4

That’s me, now click on the result to open my Keybase.io profile page.

Figure 5

Figure 5

From this profile screen you can see that I have a public key, Twitter, GitHub, Reddit accounts, and a blog (this one).  Each of these have been cryptographically linked to my Keybase account by way of an assertion and signature, my cryptographic signature from my GnuPG key ring.  To see an example on this, because you can verify each one yourself, click the blue text to the right of my blog, where it says http.

This will open up, in the browser, my assertion of ownership of the blog, with cryptographic signature attached.  (The text is generated for you, I didn’t come up with that on my own.) This assertion is checked by the Keybase servers periodically to ensure it’s still valid, but you don’t rely on the server alone to validate the authenticity.  When you use the command line client it checks again, in real time, each assertion I have on my profile to ensure they are cryptographically valid and available.  If you want to play around some more with it check my assertions for Twitter and Reddit as well.

Let’s put that into practice.  Say that you don’t know me from Bob.  What if you want to send me an encrypted message, how do you validate that the public key fingerprint listed at Keybase.io is in fact me?  Again, it’s all shades of what you will accept.  You can assert that at the time I validated each account I was in fact in control of those accounts and in control of the private key that matches the listed public key fingerprint.  A far cry better than you can do with just GnuPG and a search on pgp.mit.edu.

Note: This assertion is in fact a point in time, remember that.  Just because I asserted ownership of a website, or Twitter account today doesn't mean it's still in my control tomorrow.  It is up to YOU, the consumer of Keybase, to ensure your assertions are valid, up to date, and accurate.  We each must take responsibility, and I know that's a big ask on the Internet.

So, back to the encrypted message.  If you notice, right under my profile there’s an Encrypt button.  Click that and you’ll see a message form open with my name in the To box, and room for a message.  You can type a message in the box and hit Encrypt at the bottom.  Currently this just displays the cipher text for you to copy and paste into an e-mail client, but in the future this screen will allow you to send it straight to me, at my keybase.io email address.  Oh, did I forget to mention, everyone gets a <username>@keybase.io e-mail address that forward to your e-mail on file.  That way people can still send you encrypted messages without actually knowing your personal e-mail address.  Not bad.

Conclusion

Honestly, this is a fantastic step forward in easing the adoption of commonly available encryption methods for the public.  It’s not a solution to everything, but it’s an outstanding idea, and it’s only Alpha.  Keybase also has an API under development that would allow this functionality from any application by just making secure API calls back to Keybase.  Think of the possibilities there.  I expect great things from Keybase, and it’s adoption will be wide.  Already the demand for invites is staggering.  It took me most of the day to track one down, but it was worth it.  If you can get an invite, grab it, and try this out.  Please though, if you’re going to take it for a spin be productive and help make this product soar out of Alpha and beyond.

While my praise is high, there are in fact some caveats to point out.  First off, when you first create and account, it does offer to create a key pair for you, and store the public and private keys on the Keybase servers.  Now, Keybase does state that they never have access to your private key, and they probably don’t, but the real concern here is doing any cryptography in a browser.  The keys are likely generated locally, but doesn’t mean you’re safe from any other nefarious browser plug-ins and the like.  If you want a truly secure key pair you’ll create them on an air gapped system where the private key for the master key on your ring never hits an Internet facing system.  (Advanced key ring creation for sure.)  That’s the serious user approach, and it’s really the safest way to go.  For the average Internet user the Keybase generation method may be just fine.  Who am I to say.  Keybase had to weigh the target demographic and skill level here in their design choices.  I understand why they did this, and since it’s optional, I couldn’t care less.  However, it would be nice if they tell us if a profile has a key that’s generated that way, compared to one that’s not, and it’s easily visible.  It weighs into ones self-assessment of a profile in more serious situations.

The other caveat is the expiry of the assertions.  While they are time sensitive cryptographic assertions made to a site, or account, they seem to have an unlimited period of validity.  Perhaps in future versions we will see assertions have an expiry attached to them, to increase the validity of the claims being made.  Again this is Alpha, and I’m not concern with those things at the moment.  For all intents and purposes it’s honestly something that is so simple and elegant that you can’t help but wonder why someone hadn’t thought of it prior.